There are a number of industry trends that are pointing towards an increased importance for people to be able to contribute and guide enterprises at the more strategic level. The recently released Draft Vision for Australian Government use of ICT signalled a shifting emphasis within the Australian Government from controlling costs to ensuring that Government agencies focus on value. For a long time John Thorp has been stressing the importance of benefit analysis to successful IT-enabled investment. Early in 2011 the OGC published their Management of Portfolios (MoP) framework to tie together the underlying work of the project and programme. MoP is a methodolgy for investing in the right change initiative and balancing the organisation’s appetite for risk. Business analysts often have the right skill set needed to work with key stakeholders to facilitate the setting of direction and priority of enterprises to contribute to the creation of enterprise value more effectively. The International Institute of Business Analysis (IIBA) is starting to recognise the part business analysts can play in this creation of value through the identification of an advanced generalist competency within their third version of the Business Analysis Competency Framework. An advanced generalist business analyst applies their business analyst skills at a more strategic level than a senior business analyst.
This post begins a series that outlines the business case for advanced generalists. This post will concentrate on the objective of programmes – creating business outcomes and what has to be managed to ensure organisations achieve those objectives: benefits, project interdependencies and structured change.
Image adapted from The Information Paradox and John Thorp. This diagram shows the relationship between projects, programmes and portfolios.
I want to emphasise that this post isn’t an attempt to invalidate the valuable work performed by business analysts on projects. Project based business analysis is vital to the success of both projects and programmes of work. I’m not suggesting within this post that this important work is neglected. However there is a need for project work to contribute more than just a capability. The capability needs to be utilised by an enterprise and deliver business objectives.
Business Objectives
There are many names for the intermediate outcomes (intermediate within an enterprise wide perspective) that programmes achieve. From the reading I’ve done, there appears to be a lack of consensus as to what this term is. I’m referring to it as a business objective. This distinguishes the term from a benefit which is important to programme management, but ultimately isn’t the defining end-goal of a programme. It is also aligned to the Business Motivation Model (BMM). The BMM defines an objective as:
An Objective is a statement of an attainable, time-targeted, and measurable target that the enterprise seeks to meet in order to achieve its Goals.
Business Motivation Model Version 1.0, OMG, 2008
It also aligns with the OGC’s Managing Successful Programmes (MSP). MSP defines an objective as:
The result of change, normally affecting real-world behaviour and/or circumstances; the manifestation of part or all of the new state conceived in a programme’s Blueprint.
MSP 2007 Glossary of Terms – English
© Crown copyright 2007. Reproduced with permission from OGC
A Programme’s Relationship to Projects
A successful project is the result of the management of the triple constraint to produce a capability. This is either a new capability for the organisation or a refinement of an existing one. It’s how these capabilities are used that is important. It is the role of the programme to define how the capability is implemented to achieve a business objective. As seen in the diagram above, a capability creates a business objective.
Managing Benefits Realisation, Project Interdependencies and Structured Change
Benefits realisation, project interdpendencies and structured change aren’t constraints that a programme’s team should manage. However they are important to a programme’s success. These aren’t the sole responsibility of a business analyst to define, rather they are the responsibility of the programme team as a whole. When you think that programmes are made up of multiple projects, that programme team becomes rather large. Interdependencies between projects make the information sharing needed amongst the programme team very complex, very quickly.
The Senior Responsible Owner is looking for the programme to deliver benefits. Benefits are also defined in the MSP glossary, “a measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders”. Benefits management – identifying, defining, baselining and realising – forms one of the core aspects of programme management. A business analyst working at the programme level will be integral to liaising with the business and teasing out the benefits. The elicitation skills that at a project level are used to gather requirements, may be used to identify relevant benefits and define them. From here qualitative and quantitative analysis skills are needed to classify benefits as either tangible or intangible and if possible, to baseline them.
Structured change management is a discipline in and unto itself that was pioneered by the organisational psychologist Kurt Lewin. Elements of this discipline are relevant to programme management, which is often about achieving structured change within an enterprise. A programme can also be emergent too, so it’s not always about change management. An emergent programme comes about when multiple separate projects are identified as having interdepencies, and a decision is made to manage them holistically as a programme.
It’s obvious that in an IT-enabled programme of this level of complexity, numerous business analysts would be needed to undertake the requirements analysis. However there would need to be a coordinating business analyst role undertaken by a business analyst. That business analyst should meet the competencies of an advanced generalist business analyst.
The Advanced Generalist Business Analyst
According to the Business Analyst Competency Model 3, the advanced generalist business analyst performs similar tasks to a senior business analyst, however it is generally higher in the organisational heirarchy, interacting with people at a more senior level and dealing with a higher amount of complexity and ambiguity. “These profiles require an advanced demonstration of many Underlying Competencies [Underlying Competencies refers to the corresponding chapter within the BABOK] to effectively perform. Advanced demonstration of an Underlying Competency is seen through the context the competency is used; the behavioural indicators remain the same, while the context in which the indicators are demonstrated becomes challenging for effective performance”.
In this case, the context is working with a team of business analysts, the programme manager, managers of the underlying projects and the senior responsible owner. This requires the person in the role to have mastered most or all business analyst skills and be able to build an effective working relationship with stakeholders internal and external to the programme. As suggested above, this is familiar to a practiced business analyst. However the context and the responsibility may not be familiar to all business analysts. It is as the competency indicates, the next level up from a senior business analyst.
A lot of the tasks that an advanced generalist business analyst working at the programme level may be undertaking are defined in the Enterprise Analysis knowledge area of the BABOK version 2. This section of the BABOK outlines tasks that set the context for the requirements gathering work. Some of the most important tasks are identifying the business need and constructing the business case. Some of the specific tasks that need to be performed by a business analyst within this context aren’t identified within the current version of the BABOK. It would be nice to see future versions expanding on this skill set. Some of the specific tasks that a business analyst might perform are:
- Assisting the programme manager to create and maintain the programme blueprint
- Assisting in the creation and ongoing maintenance of the programme business case
- Responsibility for benefits management. This include benefits diagramming techniques such as benefits mapping, Investment Logic Mapping or Results Chains.
Future posts in this series will expand on the skills needed at the programme level by advanced generalists. The context of advanced generalists working at the portfolio level will also be examined.
