Tips for Business Analysts: Career Paths for Business Analysts

Author: Geri Schneider Winters

People come to the job of Business Analyst in many different ways. Some people graduate from college and immediately start to work as a junior Analyst for a major corporation. Often a Business Analyst has some years of work experience in some related field before starting to work as an analyst.

You may choose to work for a company in the role of Business Analyst, or you may be a consultant and some of what you do is work as a Business Analyst.

Once you are working as a Business Analyst, what can you expect in terms of career growth? This will depend on the experience you bring to the job and your interests.

BA’s with more experience are generally assigned to larger and/or more complex projects. If you are an experienced BA, you will be often asked to mentor junior Analysts, and depending on your other
experience, you may also be asked to mentor the Project Manager, Software Process Engineer, QA group, or even the Project Architect or Designer.

Over time, you may be asked to work on a small project as both the Business Analyst and the Project Manager. This will introduce you to the job of the Project Manager. You may decide to gain experience and certifications through the Project Management Institute (PMI) and evolve your career into management. You could work your way up through the levels of management as far as your talents and desires take you.

You may decide that you really love the BA job. Over time, you will work on more complex projects with more responsibility. You may then choose to create an internal organization for other BA’s in the company, to provide guidance, internal training, and resources such as templates or guidelines for people in that role.

You might decide you really like teaching and mentoring, so go into jobs such as corporate training or consulting. You would work to train and mentor other Business Analysts in their jobs.

You might become very interested in software development processes and become a process engineer. This tends to be a consulting position. Few companies have software process engineers on staff, though you may find such as position as part of a corporate governance or continuous quality improvement organization.

With your strength in the soft skills of listening, speaking, writing, and meeting facilitation, you can look at other kinds of careers that may interest you more than writing requirements for software projects.

For example, if you really like learning to install and use software tools, you might become a tools person – someone who elicits the corporate needs for software tools, determines what tools are needed, and how they will be used to support corporate goals. You might also be involved in creating manuals and training for company personnel to show them how to use the tools in their jobs.

Maybe business is your real passion, so you use your soft skills to become a business coach. You work with people to discover the goals of their business and how to achieve these goals. This is often a position where you work with small business owners who want to improve or grow their business.

Consider a job as a Product Manager. Note that is product not project. A Product Manager is a marketing person who surveys the market and writes the business requirements for new projects. A Product Manager typically works closely with project teams to achieve good products that meet the needs of the marketplace.

As you see, with experience as a Business Analyst, you have developed a lot of skill in listening, speaking, writing, and meeting facilitation. You may have also learned a lot about a particular domain. You can use these skills to develop further as a Business Analyst, or to go into other jobs such as Project Manager (and higher management positions), Product Manager, Tools Person, Governance, Quality Improvement, Business Coaching, Corporate Training, Mentoring, and Consulting.

For more information, Click Here to see a video on planning your BA career.

===============================================

Now it is your turn.

Are you currently working as a Business Analyst? What are your thoughts about your career? What will you do as you gain more skill as a BA?

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.writingusecases.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

Tips for Business Analysts: What are RUP, EUP, UP, OpenUP, EssUp?

Author: Geri Schneider Winters

RUP describes a process for developing software systems. It seems there are so many variations of RUP, how do you know which is best for you and your organization, if any? What do all those acronyms mean? Where are these things coming from?

RUP is the Rational Unified Process. This process is a combination of two earlier processes – the Rational Process and the Objectory Process. When Rational Software merged with Objective Systems in 1995, they began the work to merge their software development processes. This new merged process was released in 1997 as the Rational Unified Process or RUP.

RUP was designed to cover everything known at that time about how to develop software – from very large systems to very small systems. It was expected that users of RUP would customize it for their project and work environment.

RUP describes software development in terms of four phases: Inception, Elaboration, Construction, and Transition. RUP also describes software development in terms of nine disciplines: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment.

Not everyone agreed that RUP was complete or correct. Scott Ambler in particular discussed a lot of what he thought was missing in the RUP. In 2005, he and his partners released a book called the Enterprise Unified Process or EUP. This book described the missing elements of RUP. In particular, Scott added a fifth phase – maintenance – to the project lifecycle.

Unified Process or UP, was a request for proposal issued by the Object Management Group. They were thinking of creating a standard for a meta-model process – or to put it another way, a description of how to create a process. This effort was abandoned, so there is currently no UP standard.

Some people use the term UP to refer to the core elements of RUP: risk managed, use case driven, architecture-centric, and iterative development.

OpenUP is a customized version of RUP which is designed for small and agile projects. OpenUP is an iterative software development process that is minimal, complete, and extensible. It is based on managing risk in an iterative development, use case driven, architecture-centric process.

OpenUP was donated by IBM Rational (I believe in 2005) to the Eclipse foundation and the open source communitee. You may download it free at http://www.eclipse.org. Here you may also download EPF, the Eclipse Process Framework, which is a tool you can use to develop your own process or modify OpenUP. EPF is a free, open source subset of the IBM Rational tool Rational Method Composer.

EssUP – the Essential Unified Process – is a product of Ivar Jacobson International. It appears to have been released around 2006. EssUP is based on the idea of a Practice. These Practices are based on best practices from RUP, Agile, and process improvement. Practices are grouped into the categories of Iterative, Architecture, Use-Case, Component, Model, Product, Process, and Team.

For example, a Use-Case Practice describes the work flow of collecting requirements in a use-case driven approach. Along with the work flow, the Practice describes the competencies that are required to do the work of the Practice. So if your Use-Case practice requires the use of class diagrams, then one of the competencies required is that someone involved in this process has to understand and be able to produce class diagrams.

EssUP intends that a company would use the basic elements – Practices and Competencies – to describe their processes and to direct process improvement efforts.

RUP, EUP, UP, OpenUP, and EssUp are all variations of a risk managed, use case driven, architecture-centric, and iterative development process. RUP tends to be popular in large, high ceremony projects. EUP is popular with those involved with Enterprise level concerns. UP refers to the basic process that the rest are built on. OpenUP is an open source variation for small, agile projects. Finally, EssUP is a variation focusing on the practices and competencies of software development, each of which can be independently implemented at a company.

===============================================

Now it is your turn.

Have you or your company considered the use of RUP, EUP, UP, OpenUP, or EssUP?

Are you using any of these processes in your projects?

================================================

You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.writingusecases.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE