When to break a project into phases

Sometimes it is helpful to break projects into smaller chunks, called phases, and to manage delivery by phase or sub-project.

Phases should be logically coherent pieces of work. They may have dependencies on other phases, but it should make sense to manage them independently. Breaking a project into phases can reduce risk and complexity, but too many phases can make it difficult to bring them back to one coherent outcome.

There are various possible reasons for breaking a project into phases, including:

• Delivering the project in one phase has high complexity or risk. Individual phases, which can be scoped and managed one at a time, are more straightforward.
• A project is not approved because of investment limits, but an individual phase is, since the phase investment is within thresholds. Be careful doing this, as it can create problems with business cases, especially when benefits are achieved only when all phases are complete.
• There are not enough resources to deliver the whole project, or with current resources it will take an extended period of time. By breaking it into phases, the existing resources can at least deliver some of the project quickly.
• Project requirements are unclear or very volatile, and achieving clarity and completeness will take an extended period of time. A subset of the requirements is clear and this can be delivered without waiting for all requirements to be specified.
• Different parts of the project will be delivered by unrelated teams, which can work separately.
• A single project will take a long time to deliver, delaying achievement of business benefits. If a proportion of benefits can be delivered earlier, then break it into phases.

Projects can be divided into different types of phases:

• sequential
• overlapping
• parallel.

The choice of phasing depends on the context and the reason for breaking a project into phases. If the reason is resource constraints, the phases have to be sequential.

Programmes

When a project is broken into several chunks which are projects in their own right, the resulting set of projects is usually known as a programme. The term ‘programme’ refers to several different types of endeavours, including:

• Large projects – not really a helpful definition, but many people who manage large projects refer to them as programmes.
• A sequential chain of related projects, e.g. different phases of implementation of an IT system.
• A set of connected projects with a common goal, e.g. a cost-reduction programme.
• An initiative which leads to substantial organisation change, e.g. a reorganisation programme.
• A series of projects completed for a common customer within a business, e.g. a sales improvement programme.
• A complex activity that has both project and operational components, e.g. a build–operate–transfer programme for a new power station.

The use of the term depends on the situation, and usually it is not necessary to be prescriptive. In this book, a programme is assumed to contain multiple projects.

Core programme management tasks

The majority of programme management tasks are the same as for project management, although they tend to be on a larger scale. There are some tasks which are more common in programme management and are unlikely to be required in a project, including:

• Initiating projects and selecting project managers.
• Coordination between projects, e.g. dependency management.
• Consolidation of management information across projects, e.g. issues, risks, progress, reporting, etc.
• Prioritisation and resource management between projects.
• Multiple-project management and aligning multiple projects to a common goal.
• Ability to lead, motivate and direct multiple project managers.

Additionally, there are tasks which are not unique to programmes, but which tend to become more important and involved in programme management, including:

• Benefits realisation.
• Change management and managing the business acceptance of change.
• Stakeholder management involving wider and more senior stakeholder groups.
• Communications.
• Financial management.
• Understanding of interactions between programme and business governance.

Choosing a programme manager

The programme manager has to do everything a project manager does, but at a more senior level. The programme manager therefore has to have:

• Project/programme management knowledge and experience, suitable to a programme of this type and scale.
• Context-specific knowledge – both of the type of programme and of the type of organisation.
• Personal capabilities suitable for working on a large and complex activity.
• General management and leadership skills appropriate to the size and seniority of the programme management team.

The requirements for a project manager are described in more detail on page 82. In addition to project management knowledge, the programme manager should have:

• A practical understanding of business value and benefits realisation.
• A practical understanding of change management and the ability to transition deliverables from the programme to business-as-usual operations.
• The ability to interact with and influence senior managers and executives.
• General management skills that would be associated with any senior manager.
• The leadership skills to direct a significant endeavour.
• Where appropriate, knowledge of programme management methodologies such as MSP (Managing Successful Programmes).
• An awareness of governance processes.
• The ability to drive structure and clarity in situations of ambiguity and uncertainty.

Often programme managers also need to have the capability to manage third-party vendors in the delivery of all, or some, projects within the programme.

Programme reporting

Reporting programme status is similar to reporting project status (see pages 107 and 110), but is more difficult because of the scale and complexity of a programme. Additional information that can be in a programme status report compared to a project report includes:

• Commentary on programme status.
• Summary of status by project.
• Status of dependencies between projects.
• Cross-programme risks, issues, changes, etc.
• Progress towards programme objectives or business benefits.

The needs of big projects or programmes

The checklist on page 60 listed the critical success factors (CSFs) for projects. These all hold true for programmes as well. However, on top of that there are additional CSFs for programmes and the largest of projects:

• Realistic planning horizons (generally, it is futile to commit plans for endeavours which have timeframes that are significantly longer than an organisation’s strategic planning horizon).
• Effective governance processes in place.
• Acceptance of the needs for business change across the leadership of an organisation.
• Culture and management approaches which are supportive of benefits realisation.
• Senior management and executive-level support and leadership for the programme.

Portfolios and portfolio management

The terms portfolio and portfolio management are important in project management. There are various definitions of the words. The term portfolio is used as:

• An alternative word for programmes, especially those associated with a programme of work for a common customer, e.g. the sales portfolio.
• A set of projects which use the same resources to deliver, e.g. the new product development portfolio, or the IT portfolio.
• All the projects and programmes in an organisation, e.g. the XYZ Corporation’s project portfolio.
• The governance processes used to align project delivery with business strategy, and those components of strategy to be delivered via projects, e.g. project selection and prioritisation.

In this book the term ‘portfolio’ encapsulates the last two definitions in the list.

Portfolio management involves selecting the right mix of projects to deliver the outcomes required by an organisation, taking account of resource limitations. Portfolio management has the following main tasks:

1. Determining portfolio objectives and metrics, e.g. what strategic or operational goals must be achieved in the next financial year(s) by projects; what balance of projects should be invested in?
2. Selecting projects in the portfolio, which is a form of investment decision making:
   • Understand project options. Which projects can be considered for delivery? (See pages 53 to 57.)
   • Understand constraints upon delivery and what resources are available. How many and what combinations of projects can be undertaken? (See page 191.)
   • Understand and apply selection criteria, filter out or eliminate unsuitable projects and prioritise between those left. The intention is to match the projects undertaken to the resources available. (See page 189.)
   • Review the complete set of projects in the portfolio and compare this to the portfolio objectives.
3. Managing the portfolio in-life, dynamically assessing and amending it (adding, deleting or changing projects, altering relative prioritisation of projects) as a result of:
   • Project outcomes differing from plan, e.g. different resource usage, different time to deliver, different benefits stream.
   • The operational situation changing, e.g. resources on projects are required in operations, or operational problems arising which require an unpredicted high-priority project to be delivered to overcome the problems.
   • An unforeseen opportunity arising, e.g. an attractive sales opportunity which can only be fulfilled by a project.
   • Business needs changing, e.g. alterations in competitive situation, or amendments to business strategy leading to the need to change the project line-up.

(Also see page 234.)

Portfolio reporting

Portfolio reports provide a view of the status of all projects in the portfolio, and a view of progress towards portfolio-level objectives. Portfolio reports are typically produced monthly or quarterly. Helpful contents are:

• Summary of status for projects and programmes in portfolio. For a complex portfolio the summary report for each project must be short. A useful format is a traffic light status (red–amber–green), with a commentary of 1–2 sentences per project.
• Cross-portfolio issues, e.g.:
  • Common issues and risks.
  • Common sources of change.
  • Resources shortages or issues coming up.
  • Any business issues with an impact on the portfolio.
• Modifications to the portfolio: new projects started, projects finished, projects on hold or stopped.
• Status of progress towards portfolio goals, i.e. how well the portfolio is progressing towards the delivery of strategic goals.
• Key decisions and approvals required relating to the portfolio.
• Portfolio commentary, e.g. a paragraph of information with summary comments on the portfolio status.

Choosing projects for a portfolio

Core activities in portfolio management are selecting and prioritising the projects an organisation will invest in. The way projects are prioritised depends on the portfolio objectives, which in turn depends on business strategy. Ways to prioritise projects include:

• Management judgement.
• Financial assessment, e.g. NPV or IRR.
• Impact on KPIs (Key Performance Indicators), how the projects will directly improve key business metrics.
• Strategic alignment, i.e. how the projects fit with business objectives as defined in the strategy.
• Feasibility, i.e. the likelihood of achieving the project, which includes technical, operational and commercial probability of success.
• Capability development, e.g. what learning opportunities a project provides to improve business capabilities and competencies.

A good way to prioritise between projects is to use multiple criteria based on business needs. The criteria should be scored and weighted for each project. Pure scoring is unlikely to be able to take account of the complexity and reality of business situations, and there is usually a need to apply management judgement as well. Having determined the approach to prioritisation the projects can be selected as follows:

1. Filter projects:
   • Remove projects which are culturally, socially or legally non-permissible.
   • Remove non-feasible projects, e.g. those which are not possible to complete, or not possible with the organisation’s capability and an acceptable level of risk, or those projects which are operationally unacceptable.
   • Remove projects which do not meet minimum business case requirements or are outside other business thresholds, e.g. too long a payback period, above maximum scale
2. Prioritise:
   • Choose prioritisation criteria (as described above).
   • Apply criteria by scoring each project against them.
   • Prioritise projects.
   • Compare prioritised list to resource available.
   • Re-prioritise taking account of resource constraints.
3. Review:
   • Check balance of projects. Is there a selection of projects that meets the needs of different stakeholder groups?
   • Check against portfolio objectives. Will this set of projects deliver the business strategy?
   • Check compatibility of projects. Are the projects compatible? For example, do any projects have conflicting goals, or can any projects be combined?
   • Check cumulative risk. Does the portfolio have an acceptable level of risk, i.e. make sure some are low risk to balance against high-risk ones.
   • Amend according to results of review.
4. Maintain portfolio over time with periodic reviews.

Understanding human resource constraints and resolving conflicts

If there were no resource constraints, there would be no need for portfolio management, as any project with a positive business case could be delivered. To be able to decide how many projects should be done, it is important to be able to understand resource constraints.

There are various types of resources that have to be managed on a project:

• people
• money or budget
• equipment and facilities (non-consumables)
• consumables.

The focus in this checklist is on human resources, as these are complex to manage, and is the resource that typically provides the most contention on projects. There are several categories of human resources:

• Dedicated project professionals, such as project managers or business analysts, 100 per cent available for project work.
• Specialist resources who work predominantly on projects. For example, staff involved in new product development.
• People who are available for project work for a proportion of their time. An IT programmer may spend 50 per cent of his time on software development projects and 50 per cent on maintenance of existing systems.
• Operational people who are normally not available for project work, but who may be made available for specific projects.
• Contract staff, typically 100 per cent available once a contract is in place. (This requires permission to spend external budget.)

A project manager wants to ensure that sufficient resources exist to be able to complete the tasks on the project. From a portfolio level, human resources can be managed to achieve several different goals, e.g.:

• maximise flexibility and capability to respond to new opportunities
• maximise utilisation
• minimise staff costs
• maximise learning etc.

These are conflicting goals and it is important to understand which goal is paramount when dealing with resources. There are three ways to manage resource constraints:

• Resource limits – start new projects until no resource is available to do any more. This is simple, but usually inefficient and ineffective in maximising project returns.
• Detailed capacity analysis – understanding the availability of all resources in an organisation and managing access to those resources at a detailed level. This is theoretically best, but managing the detailed information to understand the availability and workload of all staff can be onerous.
• Availability tracking for key ‘bottleneck’ resources only – for example, only tracking availability of project managers. If the key bottleneck resource can be identified in an organisation – that is, the resource that usually constrains the ability to do more work – it is possible to effectively manage resources by controlling access to this subset of staff.

Without a project or programme team, a project/programme manager cannot deliver anything. Understanding what human resources are required, identifying resources, gaining commitment, keeping resources, and bringing new people in the team are critical tasks for project/programme managers. Often the key project/programme management challenge is resource management.

At some point in almost every project there will be a conflict, when the same person or team of people will be required to do different tasks. This may be within a project/programme, or across projects within a portfolio.

There is no straightforward algorithm that will resolve all resource conflicts, but the following process can be applied:

1. Ensure projects are planned in advance to give maximum warning of resource bottlenecks. During planning apply resource levelling to try and remove bottlenecks.
2. Check if the resource constraint is real. Can additional resources be brought in to resolve the problem, e.g. from operational departments or by use of contractors?
3. Apply prioritisation criteria – ideally, the highest-priority project will gain first access to the resources required.
4. Determine if it is possible to reschedule one of the conflicting projects to a later date.
5. Factor in the duration that resources are required for by conflicting projects. For example, if a high-priority project requires a person for six months continually, and a lower-priority one requires the same person for one day, it can be effective to let the low-priority project continue by providing the person for one day even if the work is of lower priority. However, you cannot continually or even regularly do this or the first project will never be delivered.