Projects, Portfolios and Programmes A Continuum from Energy to Strategy Part 3

1. Introduction

In part, 2, the following model (Figure 1) was explained and the analysis of the roles and responsibilities was provided.

The roles and responsibilities are complementary, with commonalities and differences in the way in which they are carried out, as explained below.

2. Commonalities

The commonalities relate to the “how”. However, these commonalities have to be adapted depending on the management focus to which they relate: the difference is in the detail. This is explained below.

All of the domains have the following artefacts in common:
– Definition of the reason for the endeavour
– the term “management directive” will be used to cover all domains
– Definition of the products, services or results (Statement of Work – SOW) and the corresponding features and functions to be provided (Requirements Specification and Scope Statement)
– The authorisation to apply organisational resources to accomplish the endeavour (the Charter)
– A hierarchical description (“breakdown”) of the work to be carried out to satisfy the SOW (project or programme WBS, portfolio component list)
– for simplicity this will be termed “activity register”
– Analysis of the components of the activity register (stored in the “activity register dictionary”)
– description of the logical dependencies between them
– estimates of time or effort for each component
– estimates and assignment of resources
– Proposed sequence of components to provide the “optimal” result based on the charter (providing the schedule or roadmap)
– The need to manage uncertainties that could impact the achievement of the objectives (risk management)
– All of the other knowledge areas

This has given a brief overview of the commonalities. The major differences are in how to apply the corresponding tools in each of the domains. The differences are conditioned by the definition of the endeavour from the start (i.e. the very first document: the management directive) as explained next.

3. Differences

The difference is in the detail! The types of tools or the way in which they are used can be different in each domain. One other area of difference, due to the specific domain focus, is the way in which the work is controlled. Tools and control are analysed separately below..

3.1 Tools

The tools are similar in intent but applied differently in each domain. The initial tool, the management directive initiates this chain, and is described below, followed by a brief analysis of the other tools and their characteristics.
3.1.1 The management directive
The management directive conditions the way in which the tools are applied within the domains.

– At the investor (portfolio) level, this specifies the overarching organisational strategy to be supported and the return that the strategy should deliver in the long term
– At the business (programme) level, the document describes the change to the operational environment that is needed in order to allow the portfolio goals to be achieved – the benefits capability to be installed
– At the supplier (project) level, the document provides a functional description of the deliverable required as a component of the programme
– Although the “task” is not considered a domain, it is useful to examine it as well: at the implementer (task) level, the document provides a technical description of the work to be carried out.
3.1.2 Other tools
Some ways in which these differences in focus can affect other tools are explained below. More details are given in the corresponding PMI standards.

– Definition of the products, services or results (Statement of Work – SOW) and the corresponding features and functions to be provided (the Scope Statement)
– No conceptual change between domains
– The authorisation to apply organisational resources to accomplish the endeavour (the Charter)
– No conceptual change
– At the implementer level, this will be described in the Statement of Work (SOW)
– A breakdown of the work to be carried out to satisfy the SOW (project or programme WBS, portfolio component list)
– At portfolio level, this is the “project portfolio”
– Managed as outlined in the Standard for Portfolio Management
– At programme level, this is the programme component list
– Which can (and should) also be managed as outlined in the Standard for Portfolio Management in order to provide a programme roadmap.
– At project level, this is the task list
– To be managed using the scheduling tools
– Analysis of the components of the activity register
– description of the logical dependencies between them
– frequently overlooked for portfolios!
– estimates of time or effort for each component; resource estimates and assignment
– No conceptual change
– The need to manage uncertainties that could impact the achievement of the objectives (risk management)
– No change at the conceptual level, remembering however that the scope of objectives is different for each domain
– The practical differences are explained in the different standards
– All of the other knowledge areas
– No change at the conceptual level
– The practical differences are explained in the different standards

3.2 Control

The contrast in the focus of control between the domains is the key differentiator. Although, as has been shown, the practical management in the domains overlaps, there is a need for clear management roles and responsibilities as depicted in in Figure 1. From this point of view, the type of control required by the domain client will condition requirements on the corresponding reporting. Since reporting is dependent on the tools used for tracking, and tracking – in turn – relies on the results of the planning, the specific tools used for each of these will depend on the category of stakeholder and their domain focus. This is explained in more detail next with respect to planning the schedule. Similar differences can be identified in in a similar way in the other knowledge areas.
3.2.1 Developing the Schedule(s)
Once the dependencies, durations, resource requirements and resource assignments are known, the schedule can be developed in line with the focus of the domain client:
• At the investor level, the components need to be sequenced so as to provide the path to strategic advantage constrained by resources and investment, and optimised with respect to return – using the tools described in PMI’s Standard for Portfolio Management – to create what should be known as the “critical route” linking the strategic initiatives.
o Progress should then by tracked using key performance indicators (see Hynuk Sanchez & Benoît Robert, pp 64-73, PMJ, Dec 2010, vol 41, number 5)
• At the business level, the programme management approach should be used, to link deliverables from the supplier level to the needs of the investor level, and the roadmap created using the “critical route” approach described in the previous bullet point
o Tracking should then use the Earned Benefit method (C. Piney, various papers)
• At the supplier level, the project management approach should be applied as described in PMI’s Guide to the Project Management Body of Knowledge (PMBOK® Guide) applying critical path or critical chain techniques
o Tracking should use tools similar to the Earned Value method
• At the implementer level, the best practice approach for the corresponding technical area (e.g. IT development techniques, building practices, etc.) should be applied. Reporting should comply with the rules specified in the corresponding statement of work.

4. Conclusion and Link

This section used the diagram developed in Part 2 to analyse the commonalities and differences between the domains. The final part will bring all of these concepts together to create a “project family” which – like any family – is a cohesive whole, allowing for the specific differences in each of the members.