Business Analyst: An evolving position

The BATimes published in late 2008 an article [1] about trends in Business Analysis (BA) and Project Management (PM) for 2009.The article highlighted the following points:

• Convergence of PM and BA roles
• Greater emphasis on requirements in project management
• Change in requirements approaches
• Increased use of “Agile” approach and techniques
• BABOK continuing to have an impact
• Business Intelligence (BI) continues to grow
• Less budget for conferences and training

Before any further comment on these statements, let’s turn back to the past and see how BA has evolved in the last half century [2].

In the 1960’s a software crisis started. This crisis has several origins. First, the computers were becoming more and more complex and powerful. As a consequence, software was becoming more and more complex. At this time, software engineers were not aware about business needs, needed to spend a lot of time learning new upcoming programming languages, tried to organize their development teams… Lots of projects failed, and finding solutions took a while. During this crisis, engineers understood that software development is a complex task, and figured out later that there is no single silver bullet that will address the issues faced in developing software. Still in the 60’s, the need for BAs in software projects became essential.

Defining the role of the BA has been a long process, and another crisis, in the early 2000’s, changed the industry. This crisis brought the generalization of IT outsourcing. Since then, the main trend regarding the organization of labor in IT projects has consisted of the elaboration of teams on vertical capabilities rather than horizontal. This means that instead of having a team of BAs, a team of developers, a team of testers, the idea of using cross functional teams in IT projects is now widely accepted.

Concerning the business analyst, we can find a good definition in the article “What is a business analyst” [3]. This article says that a BA is a communicator, facilitator, subject matter expert, designer, trainer, planner, manager… Indeed, the BA is in contact with all the participants of an IT project, going from the client to the final user, going from the project manager to the test manager. Back in the 60’s, nobody in an IT project developed the business side of projects. Development teams were all coming from engineering without business awareness. Today’s business analysts must be more versatile, keeping technical skills and being aware about commercial matters and business processes.


What about the future?

Back to our BATimes article [1], the skills required to be a BA have not change. The article just mentions a refinement in the role of the BA and the trend for emerging techniques.
In the last 50 years, the BA community has not been very well organized. Many techniques have been tried, experienced, combined, and tuned. The formal organization of the BA community started in 2003 with the creation of the International Institute of Business Analysis (IIBA) [4]. With this institute, some BAs started working on the “Body of Knowledge” (BABOK), which gathers the commonly used techniques. We expect this book to be more and more utilized by the BA community. We expect in particular an increased use of “Agile” techniques.

On Agile projects the primary role of the BA is to facilitate clear requirements, rather than document them or elicit them. The Business Analysts becomes more people focused and he is more involved in understanding the drivers, values and context of the business requirements than the details of the requirements themselves. Communication and a clear transmission of the requirements to the development team become crucial.

So BAs will have to provide their analysis using more graphical explanations, and less text based documents. BAs will have to refine as well their system knowledge so as to be able to draw out functional requirements from the product owner and if necessary translate them into more technical language for developers.

We expect also for 2009 a growth of Business Intelligence needs.

Business Intelligence theory looks at certain factors to make high quality decisions. These factors include customers, competitors, business partners, economic environment and internal operations. Relying on this analysis Business Intelligence can help BAs focusing on true business requirements and anticipating how clients will use their data.


At CTP we keep abreast of the latest techniques concerning business analysis and project management in order to offer the solution that better fits our customer needs. That gives us an edge in the provision of top class advisory services to our clients.

References:
[1] BATimes, Trends in Business Analysis and Project Management to watch for in 2009, E. Larson and R. Larson, December 2008
[2] Businessanalyst.wikia.com, Business Analysis: a potted history, unknown author, March 2007
[3] Businessanalyst.wikia.com, What is a business analyst, unknown author, December 2006
[4] International Institute of Business Analysis http://www.theiiba.org/

Project Success Assessment

Enter “Project Management” in the search field of Amazon and you get over twenty-eight thousands book titles. Just in the last 30 days, the online merchant has added more than forty new releases in this area of its library; that’s more than one book per day.

Project Management methodologies have been standardized, best practices are abundantly documented, and roadmaps to successfully execute a project are plentiful available. Then why does the Standish Group comes with the Chaos Report 2007 stating that a staggering 65% of the projects can be defined as “challenged” (over time, over budget, and/or significant functionality missing) or outright “failed”.



Top-10 factors affecting the outcome of a project

The Standish Group and many other authors have created their top-10 factors affecting the outcome of a project. These lists are very similar and most of them include the following items:

• Incomplete and/or changing requirements
• Low end-user involvement
• Low resource availability
• Unrealistic expectations
• Little executive support
• Little IT management support
• Lack of planning
• System / application no longer needed
• Bleeding-edge technology
• Other / miscellaneous

Once again, it seems rather difficult to understand why with so much knowledge at hand and well listed pitfalls, only 35% of the projects are completed on time, on budget, and on target.

The main reasons for these numbers can be attached to the fact that project management is not an exact science. The outcome of a project is impacted by unquantifiable human factors, by immeasurable business variables, and by incalculable external hazards. To alleviate these threats, the good project manager establishes a risk list giving him a gut feeling about his chances of success.

Project Success Assessment Tool

To replace this “gut-feeling” by more tangible numbers, Cambridge Technology Partners uses a tool allowing its consultants to rapidly forecast the success of technology projects and to help them focusing on the most threatening factors.

CTP uses its own experience combined with the statistics published by the Standish Group to assign a probability to each factor.

for example:
“incomplete and/or changing requirements” is defined to represent on average 25% of the risks acting against the successful completion of a project.
Then for each item of the list, the project manager associates a risk scale from 0 (minor risk) to 5 (major risk).

By multiplying each risk probability with its associated risk scale, and by adding all these results, the user obtains a total score. This total score is finally compared to a scale assessing your chances of project success and the actions that may be required.

The Figure 2 below shows the project success probability for the hypothetical implementation of an ECM solution. The table clearly demonstrates that the project manager should work on the risks related to the requirements and the expectations before going any further.

The tool is based on the Standish Group’s “Top 10 Chaos” and Ron Smith’s work (Project Manager at BMC Software in Houston)

Please contact Cambridge Technology Partner if you like to have a copy of the Project Success Assessment tool. If you use it, please, provide us with your feedback, so we can improve it or help you in any other ways to put your projects on the right tracks.

Cambridge’s project managers are incented to become Project Management Professionals (PMP), certified through the Institute, as well as participate in continuing education programs. Its business analysts are following a similar path towards IIBA certification from the International Institute of Business Analysis.