Category Archives: Projects

PRINCE2 themes

Themes in PRINCE2 are approaches describing aspects of project management that must be addressed continually throughout the project and are therefore applied to the PRINCE2 processes at appropriate points. They are essentially the techniques of project management.

You can see how themes fit into the structure of PRINCE2 in this diagram.

Slide8.gif

The business case theme

This is used to establish mechanisms to judge whether the PRINCE2 project is, and remains, desirable, and viable and achievable. It provides an answer to the question ‘is the investment in this project still worthwhile?’ The project manager creates the outline business case in Starting up a project and then creates the detailed business case in the Initiating a Project process.

The business case is continually updated and is used at key points throughout the project to give the project board an informed choice about whether or not the project should continue or not.

The organization theme

This theme defines accountability and responsibility, and sets out the team roles and responsibilities that need to be in place for any PRINCE2 project.
PRINCE2 does not describe jobs but rather roles which may be filled by one or more individuals, or shared by a single individual. These roles make up the PRINCE2 project management team. This team consists of the project board, the senior user role and the senior supplier role.
The project manager is a role filled by a single individual, optional roles include team manager(s) and project support.

The quality theme

This theme defines and implements the mechanisms by which the project will create and verify that products are fit for purpose. The PRINCE2 approach to quality includes customer quality expectations and acceptance criteria, the project product description, the quality management strategy, product descriptions, the quality register, the product-based planning technique and quality and approval records. In support of reviewing the products for quality, PRINCE2 also includes a quality review technique.

The plans theme

This covers all PRINCE2 aspects of creating and managing plans. It includes the project plan, stage plans, exception plans, and the optional team plans.

The philosophy behind PRINCE2 is that the required products are identified first, followed by the activities dependencies and resources required to create those products. This is known as product based planning, and is used for all PRINCE2 plans.

There are several steps to product based planning, starting with the activity write the project product description, which is used for the project plan only. The next step is to create the product breakdown structure which is a hierarchical diagram. Following this the product descriptions along with their quality criteria are generated for each product identified.

The next step is to define the sequence in which the products of the plan will be developed and any dependencies between them. This is achieved by creating the product flow diagram.

From this point on, the more traditional activities of creating a plan need to be carried out. These include identify activities and dependencies, prepare estimating techniques, prepare the schedule, assess resource availability, assign resources, level resource usage, agree control points, define milestones, calculate total resource requirements and costs, present the schedule (typically a Gantt chart), analyze the risks, and finally document the plan.

The risk management theme

This theme is used to identify, assess and control risks and, as a result, improve the probability of the project to succeed. Risks come in two flavours, a negative impact threat, and a positive impact opportunity. Both have the common thread of uncertainty, and hence are both forms of risk.
PRINCE2 has a tailorable risk management procedure consisting of four steps, identify, assess, plan, and implement. Key documents created here are the risk management strategy and the various management products that help communicate the aggregated risk within a project, these are typically checkpoint and highlight reports, end stage and end project reports, and lessons reports.

The risk register is used to capture and maintain information on all of the identified threats and opportunities related to the project. It contains the various responses and individuals who are responsible to the project manager for managing these risks, in particular the risk owner and risk actionee. Optionally a risk budget may be set aside to fund the specific management responses to the project’s threats and opportunities.

The change management theme

The change theme purpose is to identify, assess and control any potential and approved changes to the various baseline documents. The PRINCE2 approach is to treat all changes as a type of issue. PRINCE2 has a common approach to change management. Configuration management may be thought of as project asset control.
Closely aligned to change management is configuration management which is normally provided by project support. The configuration management strategy document will define the way in which this, issues, and hence changes are to be handled. Specific aspects of the change theme include the use or otherwise of a change authority, a change budget, configuration item records, product status account, issue registers and reports.

The progress theme

In any PRINCE2 project, plans and strategies are created and approved, and then project progress reports created against them. Any deviations from these must be managed by regular monitoring and control. The purpose here before is to establish mechanisms to monitor and compare actual achievements against those planned. It also includes taking corrective action so that future forecasts keep the project within tolerance bounds.

The progress theme describes in detail how the principle of management by exception and hence tolerances are to be applied to all PRINCE2 projects. It is split into two main sections; controls at project board level and controls at project manager level. It includes the description an application of management stages and describes the nature of event-driven and time-driven controls. It includes how progress is to be reviewed and reported on.

See also PRINCE2 principles and PRINCE2 processes.

PRINCE2 processes

When I have gone through PRINCE2 with people (team members, user reps) who haven’t used the approach I have always found that they get confused over the structure. Yes, the book covers what to do in some depth but there is no overview of how it all fits together.

Slide8.gif

PRINCE2 comprises four linked elements:

Principles. These are best practices that should be applied to any project that is using PRINCE2.
Themes. These represent the project management disciplines and explain why they are needed. These will be applied across all of the processes.
Processes. These show the time-frame sequence that will be followed through a project lifecycle. Each process includes activity checklists.
Tailoring. PRINCE2 is a flexible framework and can be tailored to any type of project. In my experience, most tailoring is for smaller projects and I have posts on small projects (< 1 person month) and medium projects (1 – 2 person months).

Principles

The Principles of PRINCE2 are covered in my post on PRINCE2 best practices.

Themes

The themes of PRINCE2 are also covered in another post, PRINCE2 themes.

Processes

PRINCE2 has seven processes, each with a set of activities to direct, manage and deliver a project successfully.
These processes are not applied in a simple sequence, but should be seen as a set of seven ‘toolkits’ that are replied at key time-frame points throughout a project. The following diagram illustrates how they may be used:

Slide12.gif

Starting up a project

This occurs pre-project and is triggered by the project mandate provided by senior management.

This process is there to appoint the executive and PM who then design and appoint the project management team. These include the senior user, the senior supplier and project assurance.

A daily log is created by the project manager which acts as his/her diary, but doubles as a receptacle to capture and work any known issues or risks. In addition, the lessons log is set up for the project manager to capture any known lessons from previous similar projects. This is used throughout the project on an ongoing basis, and is the source for lessons reports. The next step is to assemble the project brief.

The project brief along with the project approach are created and the project manager goes on to prepare the outline business case and the project product description. In addition the plan is created for the first stage (the initiation stage), and this is done in the activity plan the initiation stage. This information is put before the newly formed project board for them to make a decision about whether or not to invest in the initiation stage.

Directing a project

This process is used for the first time at the end of the starting up a project process, and continues until the project closes. This process is used by the project board who are accountable for project success by making key decisions and exercising overall control while delegating day to day management to the project manager.

In order to do this, there are various activities providing key decision points, and these include, authorise initiation, authorise the project activity, authorise a stage or exception plan, give ad hoc direction, and authorise project closure.

Initiating a project

This process is used within the initiation stage which is the first stage used in every PRINCE2 project. The main product becomes out of this process is the Project Initiation Document (PID), and therefore all of the activities are focused on contributing to that document. Before any planning can take place, the project must first determine how key aspects are to be delivered, and to this end there are four key documents that need to be created first.

They are the risk management strategy, the quality management strategy, the configuration management strategy, and the communication management strategy.

In parallel with these activities the risk register is set up to populate and manage all risks within the project, configuration item records are generated, the issue register is set up to manage any issues, problems, and concerns along with requested changes, and the quality register is set up to record all activities relevant to product quality management.

The next key activities are to create the project plan and set up the project controls. Because these controls are embedded within the project plan and contain such aspects as end stage assessments and reports, then these two activities occur in tandem. An important control for the project board is the number and timing of management stages within the project. The PRINCE2 project specifies those controls used by the project board and those used by the project manager.
The next logical step is to refine the business case. The outline business case formed part of the project brief but since the project plan has now been created, time scale and cost information can be used to refine the business case into becoming the PRINCE2 detailed business case.

Since the business case contains in essence the balance between cost, risk and time verses the business benefits to be eventually realized, then an important related document called the business review plan also needs to be created (this is kept separate from the PID), it outlines when benefits can be realized and how they will be measured.
All of this information is brought together in the activity called assemble the project initiation documentation, and is used by the project board to authorise the project.

Managing a stage boundary

This process is used to prepare the relevant information at the end of the stage at an event called the end stage assessment (ESA), for the project board to make a decision on what to do next with the project. If needed it is also used to prepare for an exception assessment by the project board when either stage and/or project tolerance is forecast to be exceeded. For these reasons, the only use of this process is to plan the next stage or create an exception plan. The event to determine whether to approve the exception plan is called an exception assessment (EXA). There are no other uses for this process.

Managing a stage boundary consists of the following activities:

Plan the next stage, update the project plan with the latest actual and forecast information, update the business case and report the stage end. This process therefore, will only be used at the end of each management stage, or if triggered by an exception situation.

The next stage plan is created (or updated), as well as the various strategies and plans within the PID, the issue register, the risk register, and the quality register. The project plan is now updated to reflect actual progress and future forecast along with the business case. Because products may be handed over to the operational environment during the stage then the business review plan will also be updated if this is appropriate.

The results of the stage should be reported back to the project board via a stage end report, along with an optional lessons learned report and follow-on action recommendations (if any products have been passed on to the operational environment).

If the managing a stage boundary process is triggered due to an exception situation, then in place of the next stage plan, an exception plan will be created.

Controlling a stage

This PRINCE2 process is used by the project manager, and the main purpose is to assign and monitor work that needs to be done, deal with risks and issues, take corrective action where needed to ensure that the stage remains within tolerance, and report progress to the project board. Controlling a stage means that the project should complete within plan tolerances and deliver products that satisfy their quality requirements.

Controlling a stage is normally used within any delivery management stage, ie. any stage where products are being created. This process drives the managing product delivery process which is where the specialist products are created.
This process would start by the project manager using the activity authorise a work package to give a work package to the specialist team within the process. The project manager will then use the review work package status activity to read, and if necessary take action on the regular checkpoint reports which are created at the frequency stated within the work package.

This progress, or otherwise, is then an input to the review the stage status activity to enable the project manager to take a view on the progress or otherwise of the management stage as a whole. Based on this information the project manager may use the activity, take corrective action to ensure that the stage remains on track.

On a regular basis issues and risks may arise or change, and the project manager uses the activity capture and examine issues and risks, for this purpose.

When each work package has been finished, the project manager uses the activity received completed work packages to verify delivery.

All issues, risks and corrective actions are viewed in the light of the overall stage status, and if at any point the project manager forecasts that stage tolerance is to be exceeded, this situation must be escalated to the project board via the activity escalate issues and risks in the form of an exception report.
On a regular basis as requested by the PRINCE2 project board at each end stage or exception assessment, the project manager will create regular highlight reports during a stage via the activity report highlights, and these are sent to the project board and other stakeholders. Once the end of the current stage is reached, this will trigger the project manager to use the PRINCE2 managing a stage boundary process.

Managing product delivery

This PRINCE2 process is used by a team leader, and is where all PRINCE2 specialist products are created.
This process is triggered by the project manager in authorise a work package. An optional management product is the team plan, that may be created by the team manager to demonstrate (and to use for monitoring and control ), that the work package can be delivered within the project constraints. Once that has happened, the specialist team creates the specialist products contained within the work package as described within the product descriptions and their quality criteria.

The team manager or the team themselves will create regular checkpoint reports for the project manager to determine progress made on the creation of the specialist products until such time as the specialist products within a work package had been created, quality checked, and authorised. This triggers the final activity within managing product delivery, called deliver a work package, and it is when the work package completion is communicated back to the project manager to await his or her acknowledgement that this is so.

As part of agreeing that the work package is indeed complete, the relevant configuration item records must be updated and approval records obtained to show that the products within the work package are complete.

Closing a project

This PRINCE2 process is used either within the final management stage to bring the project to a controlled close, or it may be used to prematurely close the project should that be necessary.

The PRINCE2 closing a project process is used to obtain acceptance for the project product and to recognise that the project initiation documentation objectives have been achieved. It also verifies user acceptance, that maintenance and support services are in place, to assess any benefits that have been realized, to review the project performance, and to ensure that any unfinished issues have been addressed with appropriate actions.

This process starts with the activity prepare planned closure within the project plan is updated with the final actual results and a product status account requested from project support. The activity and over products ensures that these are passed to an operational and maintenance group and the follow-on action recommendations for any unfinished work, issues and risks is documented and that the benefits review plan is updated to reflect any benefits that have yet to be realized.

The next activity is to evaluate the project and prepare an end project report which contains the lessons report. The project manager will then recommend closure to the project board to take the appropriate action. If the project board request that the project be brought to a premature close, then the activity prepare premature closure is used instead of the activity prepare planned closure.

The project is now complete.

PRINCE2 Best Practices

Best practices for PRINCE2 are called, confusingly, Principles. There are seven PRINCE2 principles and you can see how they fit into the structure of PRINCE2 in this diagram.

Slide8.gif

The best practices (or principles) are given below.

Continued business justification There should always be a business reason to start the project in the and this justification should continue throughout the project lifecycle.

Learn from experience.  Because projects are transient, it is vital that they take advantages of lessons from previous experience. These lessons are therefore explicitly recorded and implemented during each the project.  At project closure, any lessons learned are documented and stored for future projects.

Defined roles and responsibilities. Its is important that the right people are involved and know what is expected of them.  This engages all stakeholders (business, user and supplier) within the project.

Manage by stages.  Every project is planned, monitored and controlled on a stage by stage basis.  These management stages provide senior management with control points, while having the high-level plan split down into detailed stage plans. A PRINCE2 project has at least two management stages: an initiation stage and a delivery stage. Larger projects may need to use as many stages as required.

Manage by exception. PRINCE2 sets tolerances at the directing, managing, and delivering levels.  As long as forecasts are within these tolerances then each level can continue.  The moment a tolerance is forecast to be exceeded, the details and options for recovery must be escalated to the next level for resolution via an exception report.

Focus on products.  This enables an explicit understanding of the products/deliverables that need to be produced along with their quality criteria.  Because of this focus a PRINCE2 project clearly defines the scope of a project and provides the basis for planning and estimation.

Tailor to suit the project environment.  As has already been mentioned, PRINCE2 is tailored to suit the projects environment, size, complexity, importance, capability and risk.  A major document within PRINCE2 is the Project Initiation Documentation or PID. Part of the PID specifies how the method is to be tailored for any project. In my experience most tailoring in practice is for small projects – see my posts on PRINCE2 for small projects (< 1 person month) and PRINCE2 for medium projects (1-2 person months).

See also PRINCE2 processes, and PRINCE2 themes.

Small projects with PRINCE2

One of the core principles of PRINCE2 is to amend the methodology appropriate to the project requirements. In my experience this almost always means cutting it down for small, short jobs.

In the past I have advised teams and individuals a number of times on how this might look. I thought it would be worth thinking a little more formally how this works for small projects. For our purposes, lets call a small project one < 1 person-month.

 

Lets start with what makes a managed project as opposed to simply coding. In my very simplistic way (I’m big on simplicity) it’s just this. We need to know:

  • What we intend to deliver
  • How we intend to produce it
  • Who needs to know about it
  • What might go wrong.

Of course each of these is complex and involves lots of different areas (build, test, change management just in the producing part for example), but it seems to me that if you know those things you have a project.

So lets look at those areas and the artefacts we might need for each using three types of small project

1. A simple one person, less than one week job – maybe a POC

2. A one person, two/three week job – the kind of work you might be asked to do as a low priority, when you have time thing – perhaps an simple extension to an existing system or a simple online information system from a DB with no transformation

3. A two person two week job. Something significant but still not a major project. Perhaps a simple audit enhancement to a reporting system.

So the artefacts we need for these three levels might look like this.

smallprincetable

And that’s it. Simple (I hope) but covers most of the bases. Obviously there will be areas missed, but they simply represent risks. What we want is to have a level of project management which is appropriate to the actual size of the project and the potential downside if things should go wrong.

Medium sized projects with PRINCE2

For projects around 1-2 person months you need some, but not all, of the PRINCE2 artifacts. Whenever I have specified planning requirements for medium sized projects such as this I focus on the below.

At this level, planning becomes key. There are two major deliverables from the project planning process – the PID and the work plan.

The Project Initiation Document

The Project Initiation Document or PID is the primary deliverable from the specification process and describes all aspects of the project at a high level. Even for a medium sized project time spent on the PID pays dividends later. Even a cut down PID should contain information such as:

  • Project overview – Why is the project taking place? What are the business drivers?
  • Objectives – What will be accomplished by the project?
  • Scope – What deliverables will be created? What major features will be implemented?
  • Organization – Who is the sponsor? Who is on the project team? What other stakeholders are there?

So far this is a 3-4 page document. In addition you should have an excel spreadsheet containing

  • Assumptions and Risks – What events are you taking for granted and what do you think might go wrong? What is the probability of occurence and the impact (H/M/L is fine). What mitigation steps can you take and who is responsible for tracking the risk.

The Workplan

Create a workplan, including milestones, tasks and named resources. If appropriate use MS Project, otherwise Excel.

 

Execution

Once the project has been planned, execution of the work can begin.

Monitor the schedule weekly or twice-weekly.

Identify activities that have been completed during the previous time period and update the workplan to show that they are finished. See if the project will be completed within the original parameters. If not, look for ways to accelerate these activities to get you back on track and inform stakeholders ASAP. A small slippage on a medium sized project is highly visible and can cause issues out of all proportion to the project size.

Look for warning signs

These could include

  • Activities that should be completed are still being worked on.
  • Reliance on unscheduled overtime to hit deadlines
  • Team morale starts to decline
  • QA and testing activities starts to be cut back from the original schedule.

If these occur, put together a plan to ensure that the project stays on track. If you cannot successfully manage through the problems, raise an issue through project management support.

Watch for scope change requests and scope creep

After the basics of managing the schedule, managing scope is the most important activity required to control a project. Many project failures are not caused by problems with estimating or team skillsets, but by the project team working on deliverables that were not part of the original requirements. Even if you have good scope management procedures in place, watch for scope creep.

Most of us know to invoke scope change management procedures if we are asked to add a major new function or a major new deliverable to their project. However, sometimes we do not recognize the small scope changes that get added over time. Scope creep is a term used to define a series of small scope changes that are made to the project without scope change management procedures being used. With scope creep, a series of small changes, none of which appear to affect the project individually, can accumulate to have a significant overall impact on the project.

Assess risks throughout the project

Once the project begins, periodically perform an updated risk assessment to determine if other risks have surfaced that need to be managed.

Resolve issues when they arise

All projects will have issues that need to be dealt with and resolved. If possible deal with these immediately before you get swamped. At a minimum track them via an actions or issues list at every team or stakeholder meeting.

Summary

There are always complexities dealing with technology and integration, even in small and medium sized projects. Project management involves dealing with unanticipated events no matter how large or small the project is. These practices will not prevent that, but they might at least make the environment they take place in more stable and manageable.

Agile project management

It is interesting – and somewhat telling – that I have sometimes been asked by business representatives “But what does a project manager actually do?”

Of course in a traditional waterfall project this is well understood. The PM is the key person responsible for planning and delivery to the plan, managing communication, risks, changes and issues along the way.

But what about an Agile project? Surely an Agile project team is self-managing, and the business end is handled by the Product Owner?

Well perhaps. But in practice most companies who have used Agile for more than just small, discrete projects have found, unsurprisingly, that there is a need for a project management role also.

The best analogy I have seen here is from Steven Thomas

“The role of the Project Manager is subtly different when using an Agile approach. From my fairly biased view an Agile PM is more a shepherd (or sheep dog) and less a military officer. There is lots of rushing around the edges of the development team but relatively little direct control of what the team does. If you merge together a description of the Project Manager, Scrum Master, Coach, and Tracker from XP, DSDM, Crystal Orange and Scrum you get:

Gather information from all stakeholders and integrate into workable plan; log estimates; advise programmers on their estimates using historical figures; log task assignments; sustain high rate of progress; make decisions; remove impediments; build and sustain team culture; ensure team sticks to process; liaise between management and team; manage customer relationships; fend off “feature creep” and other project hazards; get agreement on the prioritisation of requirements and detailed content of timeboxes; track progress against the timebox goals/plan; collect information without disturbing the process; update plans; communicate progress; ensure that the lessons are learnt; log defects; stay calm.

Things like “remove impediments” and “build and sustain team culture” aren’t normally seen in traditional PM role descriptions. Then there are the softly, softly items like “collect information without disturbing the process” and “get agreement on …”; and notice we “log task assignments” we don’t “assign tasks”. However, when the crunch comes we must still “make decisions”.”

In their paper “Agile project management” Maven make a similar point

“Whilst the role of Project Manager and Team Leader exist as they do in PRINCE2 , the emphasis on the responsibilities is very different and this can cause some adjustment for those project managers coming to Agile from a waterfall background.

The project team is empowered to plan their work in detail and to address issues as they arise with whoever is best placed to solve them. This means that not all communication comes through the Project Manager. [He is] not formally managing the project team, but must be on hand to guide them and to help remove any obstacles that will impede their progress. At the same time, [the PM needs] to be fully aware of the progress that the project team is making so that he or she can relay this to the stakeholders and ensure they have enough information to assure themselves that the project is on track and will deliver what they need.

For project managers used to planning every aspect of their project and conveying this information to team members via detailed work packages, this lack of control over the day to day work can appear threatening. This is why trust and honesty between the team and the Project Manager is vital, as is knowing when to stand back and let the team get on with their work.”

So there you have it. More guidance, less direction. Less a military officer, more a sheepdog.

Roles in an agile programme

One of the common criticisms made of agile is the inability to scale to large systems and programmes. It seems worthwhile, therefore, to think about the differences in agile structure between a programme and a project.

Just as in waterfall many programme roles relate directly to those in a project. However the programme level is fundamentally about business outcomes rather than project outputs and therefore focusses on business change implementation and benefit realisation, functions not normally found in projects. At development level though, the responsibility is larger and coordination greater but the roles are basically the same. The Programme Manager, Product Owner and Technical Architect roles are like this, corresponding to Agile Project Manager, Product Owner and Technical Lead.

In addition a programme needs some roles that don’t appear at all in a project, notably Programme Director and Business Change Manager. Again these roles are a result of the increased scope and communication necessary in a programme and also because of the focus on organisational change.

Programme Organisation Chart

Lets look at a typical agile programme organisation.

agileorg

The people in the technical teams (product development, integration, infrastructure) have Agile project roles. The Agile programme roles are in the Programme Board (Agile Programme Manager, Programme Director, Programme Product Owner, Technical Architect) and Change Implementation workstream (Business Change Manager).

Programme Director

The Programme Director is a senior manager responsible for the overall success of the programme. He/she is the final point of responsibility at the programme level.

The Programme Director is the key manager in ensuring the programme remains aligned to corporate strategy.

Typically the Programme Director is the business sponsor for subordinate projects. They might also be the Programme Product Owner and could be the Product Owner for the Technical workstreams.

MSP actually expects a Senior Responsible Owner (SRO) at the head of a programme although it accepts that some organisations have a Programme Director instead.

Programme Product Owner

The Programme Product Owner is responsible for the entire product being delivered by the programme team. Normally the Programme Product Owner is a different role to the Programme Director but the two roles can be held by the same person. As the size of the programme grows the Programme Director will definitely have to delegate increasing amounts of product responsibility to other people. At some point the two roles split.

MSP doesn’t have the concept of a Programme Product Owner as many programmes are not about building something (although our interest is software development).

Agile Programme Manager

A Programme Manager is responsible for the programme from programme setup (including governance), through the delivery of the capabilities and benefit realisation, to programme closure. A Programme Manager has to do all the normal project tasks (Planning, Monitoring and Control, Change Management, Risk Management) but at the programme level.

In addition the Programme manager must shape the programme team including subordinate projects. They need to form the various teams, manage the interdependencies beween them and ensure the projects deliver as tasked.

Technical Architect

The senior technical person on the programme is usually a Technical Architect. They have overall responsibility for technical quality of the product including how it is structured, organised, and implemented.

Business Change Manager

The Business Change Manager (BCM) is an MSP role. It doesn’t appear in a project (Agile or not). That is because a programme is about business change and a project is about delivery of outputs.

The BCM’s role is to manage the organisation through transformation. The programme might create capability but it is up to the BCM to ensure the organisation adopts the products and whether the organisation achieves the desired benefits.

The nature of the role, including close stakeholder contact, means a BCM is usually from the business. The role can be full or part time, long term or short and are often local champions recruited to support roll out in their area.