The four types of goal driving reviews

Given the importance of staff motivation I’ve found it odd that many organisations have little structure around their annual review. Of course they have a process – typically timed around the annual pay review and bonus cycle – but often little guidance as to how the actual goals are arrived at. The most succesful reviews I have seen focus on four specific areas:

1 – task based. The fundamental tasks the business needs you to perform. An example might be “deliver the reporting subsystem for XXX within your initial time estimate”. These are the tactical things the business needs to have done. They are the most important goals, but also the most subject to change. In many companies these are the only goals given

2 – role based. These are goals aimed at increasing your effectiveness in your role. They might typically involve training, mentoring (being mentored), attendance on conferences or generally doing somethng which increases your effectiveness in your role

3 – strategy based. These are the longer term goals which contribute the overall IT vision, for example “work with QA to develop a robust set of automated tests addressing all bugs found within your sprints”. Of course this depends on having a goal and vision for IT itself, and we address that later

4 – personal development based. These are based upon your personal development goals. The trick here is to align personal develpment goals and aspirations with the needs of the company. Arguably these are the most important goals; after all,  if you only have (1) you have someone doing a job, if you have (2) you have someone learning to be better at their job but not moving on in their career, if you have (3) you have a person who feels involved with and part of a larger whole. Only when you have (4) do you have someone who is delivering, happy and has a career path within the company.

So lets look at each of these types of goal.

Task based

IT strategy and vision

The vision for 2013/14 is “Engineers feel that their job is important and they can make a difference. They are excited by the prospect of creating something new and innovative that matters to our customers. They work to a routine which they believe is the best in the world. They can be counted on to deliver new features faster and to a higher quality than our competitors.”

The strategy is “Embed a development culture to deliver to committed timescales in a deterministic, repeatable and predictable manner. Strengthen key strategic areas with the best skills and talent to build a highly energised, effective and disciplined team. Provide our customers with the best products by developing a culture that enables the development team to innovate and deploy new features faster than our competitors.”

The Goals for 2013/14 to deliver the strategy are:-
1. 80% Sprint Predictability
This means that 80% of the stories commited to are delivered within the planned sprint. Why not 100%? Well because if we consistently hit 100% then by definition we are not setting our sight high enough!

2. 80% bugs contained in Development/QA
This means that 80% of the total bugs found are within the sprint dev/QA process – not within Integration Test or UAT.

3. 90% Requirements and Design Stability during sprints
This means that 90% of stories within a release are not changed within that release. Obviously stories change – that is arguably the point of Agile. However there is a difference between changes due to more detailed technical planning and changes due to fundamental changes in architecture. These are what result in stories being stopped and re-planned/ rescheduled, and these are what we want to minimise.

This feeds into a maximum of 4 objectives:-
1. Role Based Objective – typically “deliver x by y”
2. Predictability Objective to help secure the 80% of deliveries being on time
3. Quality Objective to ensure that we contain 80% of bugs before we release
4. Requirements and Design Stability to ensure that we have stable requirements and design before we start our sprints
The R&D LT will track each goal at the department level and publish these on a monthly basis so that there should be no surprises at year end.



Team leadership in IT

Its accepted that team management should be situational, based on a) the goals of the team and b) the team itself. The classic situational leadership diagram below goes from a directive model (lower right) anti-clockwise based on the competence of the team to one of delegation (lower left).


I have always found supporting / empowering far more effective in IT than directive. This is for two reasons. Firstly, I believe that most people in IT are highly trained and motivated to do a good job, and the role of the manager is to ensure they know what a good job is (what’s required) and to facilitate the doing of it (to remove blockers and problems).

Secondly I believe that management is best when it is about both delivering what the organisation needs and growing the members of the team. This was probably put best by Ralph Nader when he said “I start with the premise that the function of leadership is to produce more leaders, not more followers.”.

That’s my personal approach. I keep in touch with thinking on team management though, because it is so important to the business I am in. As part of this I came across some research that I think is worth sharing.

Project Oxygen

In the late nineties Google undertook a project to analyse all of the data they had regarding what made effective managers. The project, Oxygen, was widely written up at the time – mostly along the lines of “is that it?”. And in fact most of the rules they came up with are what you would perhaps expect.

The interesting thing though, is that the rules are in order of importance and the order is absolutely not what you would expect. Here are the rules they came up with:

Eight good behaviours

1. Be a good coach
– Provide specific, constructive feedback, balancing the negative and the positive.
– Have regular one-on-ones, presenting solutions tailored to your employees’ specific strengths.

2. Empower your teams and don’t micromanage
– Balance giving freedom to your employees, while still being available for advice. Make “stretch” assignments to help the team tackle big problems.

3. Express interest in team member’s success and well-being
– Get to know your employees as people, with lives outside of work.
– Make new members of the team feel welcome and help ease their transition.

4. Don’t be a sissy: Be productive and results-oriented
– Focus on what employees want the team to achieve and how they can help achieve it.
– Help the team prioritise work and use seniority to remove roadblocks.

5. Be a good communicator and listen to your team
– Communication is two-way: you both listen and share information.
– Hold all-hands meetings and be straightforward about the messages and goals of the team. Help the team connect the dots.
– Encourage open dialogue and listen to the issues and concerns of your employees.

6. Help your employees with career development

7. Have a clear vision and strategy for the team
– Even in the midst of turmoil, keep the team focused on goals and strategy.
– Involve the team in setting and evolving the team’s vision and making progress towards it.

8. Have key technical skills so you can advise the team
– Roll up your sleeves and conduct your work side by side with the team, when needed.
– Understand the specific challenges of the work.

Three pitfalls of managers

1. Have trouble making a transition to the team
– Sometimes, fantastic individual contributors are promoted to managers without the necessary skills to lead people.
– People hired from outside the organisation don’t always understand the unique aspects of managing at Google.

2. Lack a consistent approach to performance management and career development
– Don’t help employees understand how these work at Google and doesn’t coach them on their options to develop and stretch.
– Not proactive, wait for the employee to come to them.

3. Spend too little time managing and communicating

So technical skills – which you would perhaps expect Google to major on – was the least important (a common mistake though – see my post on Recruiting project managers for my thoughts on this point). Having a clear vision and strategy (which almost always comes in at number one on similar lists) is similarly less important. What was at the top were soft skills – coaching, empowering, taking an interest in people.


What does this tell us?

Well remember these were people at Google – managing highly paid, highly motivated, intelligent self starters. But then so are most people in IT. So the key point for me is that most of your team members need support rather than traditional management. Which fits in with the point I made at the beginning – obviously we need to ensure people know what is needed and are focussed, but then think mentor and facilitator rather than director and dictator.


Project oxygen

Portfolio management

There is an established literature on IT portfolio management. I am particularly interested in how this works in an Agile environment, but before I can start to examine that aspect, it is valuable to review what I mean by IT portfolio management generally.

What is IT Porfolio management

Portfolio management is a way of looking at our IT assets not as individual assets but holistically. This is valuable because it lets us balance costs, risks and investments as a whole – enabling us to set strategic objectives for, as an example, what we consider to be an acceptable balance between potential benefits and risks and what our target rate of return is on the investment overall. Having decided on those strategic parameters it is the job of portfolio management to ensure that the investments we make in IT viewed as a whole meet those objectives.

Therefore the portfolio management function has a different perspective from the strategic planning function or the project/ programme management function.

portfolio priorities

What does the IT Portfolio consist of

When IT portfolio management first became prevalent in the 1990s it focussed on project management – the investments it was concerned with were primarily development. As the technique has matured, it has expanded to include the whole of IT investment

  • Applications (existing applications)
  • Infrastructure (both software and hardware)
  • Projects and programmes.
  • Thus the scope of portfolio management has increased dramatically to reflect better the assets managed by the IT function. With that in mind, simply listing those assets becomes a) a large undertaking, and b) valuable in itself.

    Having done so however we can categorise investments by their value and potential value to the business. In my experience a major part of IT investment is concerned with “keeping the lights on”, in other words keeping the existing IT facility running. So, a large part of our investment is maintenance – mostly BAU, sometimes more strategic changes to infrastructure.

    Resource allocation

    We therefore might categorise our portfolio in this way, enabling us to have a first cut at investment priority based upon our appetite for risk and the amount we might consider reasonable to spend in each area based upon previous experience.

    portfolio asset classes

    Project prioritisation

    Next we look at the projects we are funding, after all these are the discretionary investments we are making so it makes sense to see what value we are getting and what risk we are incurring.

    We can look at each of these separately and then make our prioritisation based upon the value we place upon IT as a strategic tool:

    portfolio boston square value

    Or take a more risk based view:


    Performance tracking

    The final process is to track performance to ensure that the portfolio is delivering the benefits we planned. The nature of portfolio management changes here, from strategic planning to project tracking.

    portfoio tracking

    This is where the feedback loop occurs and where events and changes in the environment or in our plans update the portfolio. The objective is to ensure that although projects change, are put on hold, or are started, the overall portfolio continues to reflect our business strategy.

    Agile portfolio management

    So that is (very quickly) IT portfolio management. Interestingly portfolio management has up to now focussed very much on waterfall projects because of the top down focus inevitable in strategic planning.

    What I am interested in is how that works in an Agile environment. In my next post I shall address that specifically.

    Project based rightshoring

    For over twenty years offshoring has been a major part of many UK companies delivery strategy. As you would expect, the industry has matured in that time and has fragmented in to a number of specialised forms

  • Offshoring
  • Nearshoring
  • Rightshoring.
  • In my time at O2 we evolved a fairly sophisticated model for partner offshoring and, while it may not be appropriate for everyone, I feel it would be useful to describe how it worked for us.

    First, though, lets define the three key approaches.


    Wikipedia defines offshoring as

    the relocation by a company of a business process from one country to another—typically an operational process, such as manufacturing, or supporting processes, such as accounting. … More recently, offshoring has been associated primarily with the sourcing of technical and administrative services supporting domestic and global operations from outside the home country, by means of internal (captive) or external (outsourcing) delivery models.

    For our purposes we are interested in a subset of that concerned with IT development and maintenance. I would also say that offshoring for our purposes involves moving business processes to a country in another continent – typically India, but increasingly China, Philippines, Malaysia and latterly countries in Africa.


    Back to Wikipedia and we have nearshoring as

    the transfer of business or IT processes to companies in a nearby country, often sharing a border with your own country.

    Again, lets be a little more specific than nearby, and restrict it to a country in the same continent. Nearshoring for the UK therefore typically means moving business processes to the Eastern Bloc.


    Wordspy defines rightshoring as

    Restructuring a company’s workforce to find the optimum mix of jobs performed locally and jobs moved to foreign countries.

    In other words rightshoring means moving some, but not all, business processes offshore (or nearshore) depending on the business process.

    So having defined our terms, what are the advantages and disadvantages of them?

    On the positive side we have

    Cost: Cutting cost and taxes is the main reason behind companies embracing offshoring.
    Time Zone Advantage: Offshoring gives companies the advantage of exploiting the time zone by receiving round the clock benefits.

    Of course it’s not all upside. Problems include

    Differences in work practices and culture. A huge difference always remains in the work practice and culture which are hard to overcome
    Communication Barriers: It is often difficult to communicate with companies in other countries that speak a different native language. Face to face meetings are very expensive to conduct and video conferencing may not always be convenient due to time difference.
    Finding good offshore partners: It can be hard to find a good IT provider based on the reviews on their websites and few teleconferences. It is not easy to make a good judgment without proven track record of working for other international companies and authentic references.

    You can see that rightshoring is an attempt to get an ideal mix of cost and flexibility at the organisational unit level. The problem is that in terms of delivery we want to make that tradeoff at the project level. We don’t want to decide where all projects will be developed and then be stuck with that decision – we want to make it on a per project basis and ideally be able to change it if our needs change halfway through.

    Essentially that is what we did at O2.

    Project based rightsourcing

    We had a team based in UK and another, larger, one based in India. At the initiation stage of a project we would produce a high level estimate based on Agile story points. We also asked the business owners to give us a simple view of the urgency based on H/M/L. All of the H priority projects were developed completely in UK using Scrum. The default for M projects was for an initial detailed impact assessment and design to be carried out in UK and the build to be carried out in India. All L projects were carried out in India completely using a waterfall approach (as it happened they also had a daily standup but it was really just to review progress against the plan).

    Of course to do this we had to put in place a number of processes to make it work. The key ones were:

  • A BA team in UK, a core development team in UK (small) and a core development team in India with a shadow team in India whose role was to work with developers in India and become familiar with the UK projects and infrastructure. The shadow team was typically in training
  • Where possible we shared work between the two core teams, every UK team had at least one India team member attending the standups and working as a productive part of the team
  • Bi-weekly planning meetings looking 6 weeks ahead. All H priority projects were done in UK, but the rest depended on available resource. We tried to balance resource between UK and India while meeting our SLAs for planned work
  • If that could not be done we would move one or more teams from the core group between UK and India as required, then replace them with members of the shadow team
  • An administration group tasked with organising visas and accommodation.
  • The nett result was that we were able to develop systems either on or offshore based on the trade-off between cost and delivery time. The amount of each varied – that was the point, after all – but we found it worked within the below parameters.

    team size

    There were some caveats – you need a certain amount of work in the UK as mentioned – but in general it worked for us.

    Stakeholder planning

    Having performed stakeholder analysis the next stage is planning how you will engage them. There are lots of approaches to this, my favorite (as always) is to keep it simple. Regardless of whether you have a specific goal or a more long term interest it is important that efficient, cost effective communication approaches are used. Push communications are appropriate for low interest/low influence stakeholders where attempts at partnership would be a waste of time and money. Collaboration and partnership are appropriate for key players – stakeholders with high influence and high interest who could bring benefits to the organization or project, but who if not managed may bring considerable risk.

    The diagram below illustrates the relationship between stakeholder influence/power and stakeholder engagement approaches.


    You can see there are a number of planning/ engagement approaches that could be taken.


  • Shared accountability and responsibility
  • Two-way engagement joint learning, decision making and actions.
  • Participation

  • Part of the team, engaged in delivering tasks or with responsibility for a particular area/activity
  • Two way engagement within limits of responsibility.
  • Consultation

  • Involved, but not responsible and not necessarily able to influence outside of consultation boundaries
  • Limited two-way engagement; organisation asks questions, stakeholders answer.
  • Push communications

  • One way engagement
  • Organisation may broadcast information to all stakeholders or target particular stakeholder groups using various channels e.g. email, letter, webcasts, podcasts, videos, leaflets.
  • Pull communications

  • One way engagement
  • Information is made available stakeholder choose whether to engage with it.
  • Use the Stakeholder planning model above to review your communication plan and stakeholder analysis. Make sure that your engagement approaches are appropriate to each stakeholder group. Check that your communication plan isn’t over reliant on push or pull communications and that you aren’t planning to spend too much time in face to face consultations with the less influential stakeholders. Consider whether more costly push communication methods like printed materials can be replaced with cheaper options like email, online surveys or online newsletters.

    Once you have reviewed your plans you need to pull your work together to form your stakeholder engagement strategy. This should contain the following sections:

  • Purpose of the document
  • Project background
  • Introduction
  • Stakeholder analysis and rationale
  • Stakeholder communication plan.
  • These are in my experience the key steps in stakeholder planning.By now, you know who your stakeholders are, you have identified the key players and you have a plan for engaging with them. You are already way ahead.

    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.


    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.


    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).


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


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


    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:


    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.


    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.


    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.



    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.


    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.