Are you a PRINCE2 BA?

//Are you a PRINCE2 BA?

I have always been a massive advocate of planning. This is rooted in an adage that I often heard as a child growing up in Nigeria which states that “failing to plan is planning to fail”. It is also rooted in my experiences as a Change Professional where I have learned numerous lessons on planning regardless of whether a formal structured plan was demanded of me or not.

For this reason, Project Management has always held a great deal of interest to me due to the role planning plays being an integral element regardless of methodology and even though I regard myself as a Business Analyst through and through, I have been thrust into the PM space more than a few number of times and have come to regard Project Management knowledge and skills (particularly around planning) as a very important competency for any BA.

This article will not go into the intricacies of planning and though tempted, I will not talk too much about my lessons learned for failing to plan (and boy do I have a number of those – particularly from my days as a school teacher). However, l will briefly relay a number of instances where the PM skill set have been critical to my delivery as a BA

1. Completing an analysis piece within a new domain with multiple dependencies – producing a detailed approach plan enabled me to manage stakeholder expectations and monitor dependencies

2. Managing a work stream – producing a detailed plan to support task management, quality control and issue identification was key to on-time completion of BA deliverables.

3. Deputising for the PM – this often happens within projects depending on professional strengths within the team and/or project stage or just simply resource constraints –  being able to pick up the project plan and just run with it is quite handy.

4. Managing a BA team – approaching this as a project in and off itself with key milestones while working towards defined objectives I found quite useful in keeping the team focused, supporting continuous improvement and providing structure.

It is no surprise therefore that I have been exposed to PRINCE2 for a significant part of my project experience which culminated in me taking the exam if only to tick the box! However, in the process of getting certified, reading the PRINCE2 manual strongly reinforced a great number of principles I hold dear as a BA. The common assumption is that PRINCE2 is aimed at Project Managers or aspiring Project Managers (after all it is a Project Management framework) but this is not altogether accurate (Lindsay Scott’s article is quite apt for further reading on this here). This write up is me attempting to share my thoughts (jumbled as they may be) and complete a kind of mapping exercise between PRINCE2 and the Business Analyst role.

PRINCE2 is a world renowned approach to Project Management. It is the second version of the “Projects iN a Controlled Environment framework which derives its origin from a methodology developed by Simpact Systems way back in 1975. The latest incarnation of the methodology is owned by AXELOS.

PRINCE2 espouses 7 Principles, 7 Themes, 7 Processes and 6 tolerances (Time, Cost, Scope, Quality, Benefit and Risk) derived from an evidence-based study of successful and unsuccessful projects. These integrated elements ensure efficient procedural safeguards and a higher likelihood of project success.

PRINCE2 as a framework avoids being prescriptive by allowing the approach to be tailored to each unique change or organisational context thereby ensuring it remains a generic method that can be applied to any field. According to the PRINCE2 manual, the 7 Principles ‘…can be applied regardless of project scale, type, organization, geography or culture’ (PRINCE2 manual p.11).

Already we can begin to see a mapping between the PRINCE2 Principles and Themes and the Business Analysis Core Concept Model (BCCM). According to BABOK v3, ‘the BCCM is composed of 6 terms that encompass what business analysis is and means to those performing business analysis tasks regardless of perspective, industry, methodology or level in the organisation’ (BABOK V3 p.33)


 



The PRINCE2 Themes are pretty much the Knowledge Areas of Project Management while the PRINCE2 Principles are the signature of a truly PRINCE2 project. Therefore the PRINCE2 Principles and Themes, much like the BCCM, features regardless of “…perspective, industry, methodology or level in the organisation”

This non-prescriptive guidance of PRINCE2 is most prevalent in the Manage Product Delivery process which is used by the Team Managers to plan and deliver work packages. It is at the level of the Work Package that changes to product specifications are implemented. However, PRINCE2 states that production of a plan for delivery of the work package is discretionary while even the role of Team Manager itself is optional depending on the size and type of project.

I like to refer to the Management Levels as the 4 Ps of change delivery. Namely:

1. Portfolio
2. Programme (Programme Manager)
3. Project (Project Manager)
4. Package (Team Manager)

In this regard, the Business Analyst should be regarded as a Team Manager within the PRINCE2 framework because the Project Product Description and the Product Specification Documents for each stage are usually the Business Analyst’s responsibility.

The BA’s primary concern in a PRINCE2 project could be also addressed through the role of Senior User, Senior Supplier or Team Manager.

  • As a Senior User – the BA supports the specification of acceptance criteria for the project product and quality assurance. The BA is also critical to Benefits Realisation by leading on the development and execution of the Benefits Review Plan.

  • As a Senior Supplier – the BA supports the specification of solution requirements, functional design of the project product and quality assurance.

  • As a Team Manager – the BA supports the management of technical delivery of the project product and quality assurance.

  • As a Project Manager – The BA may also be engaged in a pre-project role by supporting the development of the Project Mandate through conducting a Feasibility Study.

In all of these activities, it is crucial that the BA employs an evidence-based approach to planning techniques such as estimating and scheduling as well as rigorous quality review in order to ensure the overall plan is adequately aligned and supported by the BA plan and not working at cross purposes.

The importance of planning the BA task is also highlighted by the first activity in the BABOK which requires definition of a Business Analysis approach and plan. Therefore, it stands to reason that a measure of the rigour applied to creating the Project plan should also be applied to the BA plan. The planning and execution of the BA tasks should also incorporate the guiding principles and themes of the PRINCE2 project. In concrete terms, this could be expressed as a mapping of the Business Analysis Knowledge Areas as follows:

Business Analysis Knowledge Areas & PRINCE2 Principles
1. Strategy Analysis and Solution Evaluation      [Business Justification]
2. Requirements Management                            [Manage by Exception]
3. Planning and Monitoring                                  [Manage by Stages]
4. Elicitation                                                         [Learn from Experience]
5. Elicitation, Collaboration                                  [Define Roles & Responsibilities]
6. Requirements Management                            [Tailor to Environment]
7. Analysis and Design                                        [Focus on Products]

Business Analysis Knowledge Areas & PRINCE2 Themes
1. Strategy Analysis and Solution Evaluation      [Business Case Theme]
2. Collaboration                                                   [Organisation Theme]
3. Analysis and Design                                        [Quality Theme]
4. Planning and Monitoring                                  [Plan Theme]
5. Requirements Management                             [Risk Theme]
6. Requirements Management                             [Change Theme]
7. Requirements Management                             [Progress or Control Theme]

The PRINCE2 processes represent more of a chronological framework for managing projects and this can also be mapped to the progressive and incremental development of knowledge of the problem/solution domain during the course of business analysis. This very much represents the iterative cycle of enquiry from problem and stakeholder (identification) to solution requirements (elicitation, verification and validation) and could be implemented in Agile as much as in Waterfall.

Business Analysis Knowledge Areas & PRINCE2 Processes
1. Strategy Analysis                                                [Start Up Project]
2. Strategy Analysis                                                [Initiate Project]
3. Requirements Management                               [Direct Project]
4. Requirements Management                               [Stage Boundary]
5. Elicitation & Collaboration                                   [Control Stage]
6. Analysis & Design                                               [Manage Product Delivery]
7. Solution Evaluation                                             [Close Project]

 

Agility
PRINCE2 is not a plan driven approach and therefore should not be unfairly associated with Waterfall software development delivery alone. PRINCE2 is actually a PRODUCT DRIVEN approach which means the definition of the Solution Specification precedes and dictates the tasks and activities that will be completed to deliver the solution. it is essentially iterative with the Business Analyst playing a key role re-validating the business case as must be done at every control stage and generating options analysis to be fed into exception reporting and management. Incorporating the PRINCE2 approach into the BA tasks essentially involves a cycle of Planning (approach), Identification (stakeholders), Elicitation (needs and impacts), Definition (requirement specification), Refining (requirement validation and change where necessary)

 

This allows PRINCE2 to be applied in either a Plan Driven or Change Driven manner. However, while the Manage by Stages and by Exception principles allow for appropriate governance and project gate structures to ensure continued project viability, these stages could also be increased in number and reduced in duration to accommodate a more iterative approach to product development. In this instance, the overall governance gates would sit with the Product Owner who has the opportunity to pull the plug at the end of each iteration.

Project Board Roles (e.g. Scrum)
1. Product Owner            [Executive]
2. Scrum Master             [Project Manager]
3. Senior User                [Business Analyst]
4. Senior Supplier           [Developer]
5. Quality Assurance      [Tester]

In conclusion, while these mapping exercises are relatively offhand, they do present some interesting parallels. The PRINCE2 Themes actually apply to everything and cannot be mapped strictly to a single specific Business Analysis Knowledge Area in much the same way that the BCCM also apply to everything so that they become a universal yardstick in any conversation. Perhaps, it is worth asking the question, how much of Project Management is actually Business Analysis and how much of Business Analysis is actually Project Management? In my contribution to the debate, I am more aligned to the BCS Business Analysis text which goes much further than the IIBA BABoK to identify Project Management as a Business Analysis competency (3rd edition mentions PMI and APM).

I believe strongly that with reference to the PRINCE2 Principles and the Business Analysis Core Concept Model, there is no difference at all in their manner of application. In this sense, a BA is like a PM who focuses on nothing but meeting the business need and what PM would not be equally concerned as much about Value and Quality as they would Cost and Schedule? The real divergence appears at the detailed level of each stage of the Project where the PM’s concerns include a number of governance parameters in order to successfully ‘Control the Stage’ while the BA’s concerns remain focused on managing the delivery of a specific analysis product utilising his/her specialist skill set (e.g. root cause and scenario analysis, process and use case modelling etc.), submitting checkpoint reports as required.

It is however important to note the distinction between role as ‘title’ and role as ‘function’ for these disciplines because the practice of business analysis (function) is not restricted to the ‘business analyst’ (title) just as my argument that the practice of ‘project management’ (function) is very much or should be a part of the business analyst’s (title) approach.

 

Therefore, I would strongly recommend PRINCE2 as a very useful supplement to the BA who is intent on introducing a level of rigour and control to their scheduling and estimating of BA tasks and quality assurance of BA deliverables. To be honest, I do not believe my thoughts are significantly original and this is obvious from the number of certified BAs who also hold PRINCE2 or PMP certification. In much the same way that a competent PM must employ a proficient level of business analysis skills, so also should Business Analysts be recognised as competent PMs completing Quality-specific tasks. However, what I have found is that the slant usually seems to be towards Business Analysis as a skill set within the Project Manager’s bag while in my experience, there is an equal argument for very much the reverse.

2,675 Comments