Figure of 8 – Project & Project

PROGRAMME / PROJECT DELIVERY  Fig8no77marketservice

This stage has three diagrams at a high, medium and detailed level that define the process at different levels.

  • High level – conceptual to allow links to other components in the organisation
  • Medium level – provides easy view of end to end process
  • Detailed level – checklist of tasks to ensure successful project

Moving into Practical tips from detailed theory?

Did you find project management easy to get to grips with?  It’s a bit of theory, business, process, people management, cultural behaviour, and more. The key is to take a proven  practical approach, agree expectations and track through to delivery, hand in hand with the sponsor.  While all of us can easily discuss 80% of our approach, here we focus on the most painful 20% that is difficult to solve.  We make the 20% easier.


  1. Engagement stage – to get everyone on the same page

Defines exactly what needs to be read, understood, actioned and agreed by the sponsor, stakeholders, before the project starts.  Creates and refines to baseline.

  1. Baseline – – signs off every page

Balancing your benefits, quality, scope, pace, cost, and risk level within the chosen methodology, set tolerance, team roles and dynamics, metrics, reporting and environment to communicate the right viable baseline.  Communication to all at kick off.

  1. Delivery –- manages the team to tolerance

Maintain positive relationships between the team and with the stakeholders and sponsor, and remove barriers, as they arise.  Put products and service deliverables on to a shelf ready for transition into service, as they are approved.

  1. Completion – – everything is finished to quality

Making sure that your project follows and lands the service delivery requirements, with acceptance by all.  The deliverables are ready for transition from a project that used Waterfall or Agile.  The Portfolio Board reviews project progress and service transition against strategy and investment management to balance the books. Additional work may be added to the Portfolio Selection process to fill gaps or improve services that do not meet KPIs.

The purpose of establishing the framework described here is to make the various human behaviours work together well to a common clear goal, and manage deviations to plan.

To make things go perfectly, keep the alignment right, processes clear, so the teams work well together, and maintain accurate metrics.  This is no difference in running good programmes, project, programme offices, change management, transformations, or service management. It is not supplier management, project management or information technology; it is about people in business, and the most important part is the people.



Each project sets a target to deliver its part of the strategy segment and this is a point of reference throughout the project.  The Project Manager works within a tolerance of delegated authority, provides regular checkpoints, and works with the sponsor to adjust plans if tolerance is exceeded.

HOW – Governance

The Project Manager is responsible for delivering the baselined project as the team leader, ensuring  stakeholders are in line with the agreed vision, for the sponsor.  On a day-to-day basis, managing a programme is very similar to a project.  It is just that the former is often bigger, with more complex dependencies.

As they become more complex and larger, more effort is needed on the interfaces to ensure that the project manager’s deliverables link into that final portfolio need.  However the more a defined scope can be delegated across the team, the easier it is to oversee progress.

Programme meetings are short and sharp. If someone other than the programme/project manager wishes to speak then they will very quickly understand that their communication must be helpful.  Team members must focus on the programme, not themselves. Threats to the project are covered in the risk meet (normally weekly). The programme cannot be run as a democracy, but people can challenge maturely and intelligently.

Reporting well and keeping to tolerance is the check and balance throughout.  Sponsors need to agree enough leeway from the outset.

  • Some projects are low risk and relatively easy to deliver, so lower tolerance can be set, as you have confidence that plans will be met throughout.
  • Some projects are high risk, complex and unpredictable.
    • Setting a tight tolerance will only need to many exception plans.
    • Teams will spend too much time on planning.
    • It is far better to measure team performance from the baseline, so that the estimation model can be tweaked as you understand the resource utilisation.
    • If you set appropriate tolerance levels, you allow the project manager to work to a ceiling.  Most of the time they will be empowered to deliver, but the sponsor comes in to help as appropriate.

Profit comes from delivering the “Figure of Eight” process:

  • Adherance to tolerance reduces re-planning along a path where a single person drives the team to a target.
  • Risks are mitigated and contained, so they do not become issues.  
  • The reporting mechanism, set within the terms of reference, provides regular updates to the right level at the right time. It is more than time and cost. 
  • Successful projects and programmes track quality, risks, benefits and agreed changes to scope.


The project scope and target is set through the Portfolio Manager, with agreement of the Sponsor.  Deliverables are defined as products with clear quality to deliver benefit.


The project manager is responsible for delivering the project target for the sponsor, through gaining approval of a baselined plan, and delivering defined products with tolerance.  Tolerance ensures that the sponsor is aware of delays, based on a pre-agreed threshold.

 WHENtable unzipped

It is not just about time, as Projects have 6 parameters – time, cost, quality, risk, scope, benefits.


  • Agile fixes time and generally uses MOSCOW to prioritise the deliverables, setting the minimum viable product as 60% ie Must, 20% Should and 20% Could.
    • It provides some flexibility in delivery.
    • It delivers incremental change through stakeholder agreement.  It will prioritise product and project scope to a fixed timeline.
    • Ideally you deliver everything, but with the option to negotiate to remove some of the should, and even the could.
    • You cannot fall below the Minimum Viable Product (MVP) in the fixed timescale, or the incremental delivery fails.
  • Waterfall needs to think carefully about project horizon and the depth of the plan.
    • If you believe that you can create a detailed plan for months ahead, that has detail defining processes, you could be changing the plan regularly or even constantly!.
    • Estimation of the baseline is typically +/- 60%, but will improve as the estimation model feeds future planning that breaks down the coal face pitched at the project horizon.
    • Clear short plans will guide everyone on the project and give the team clear dates, which can be met.

Cost:  In practice, cost is fixed through agreement of resource in the Strategy and then setting the project scope in the Portfolio Management selection process.

  • Budgets will be adjusted, but will naturally be commensurate with the project profit.

Quality:  Quality criteria are often assumed at the outset, not tracked and often badly reviewed at the end.  Service management absorbs the pain of the failure, but the business needs to recover  through correcting bugs, products, processes etc.  The impact can be considerable and organisations will save through:

  • Well defined baselines across all steps and parameters
  • Traceability matrices that track the development of quality until products can be “put on the complete shelf”.
  • Strong release process, with proper sign off stages for infrastructure, applications, products…

Risk:  Organisational risks are captured as we move through the figure of 8, followed by tracking of specific project risks.

  • Transparency helps stimulate mitigation.
  • Peer pressure draws people to mitigate.
  • The risk review process needs to be established, regular and supported.
  • Thresholds for escalation need to be in baseline documentation at organisational and project level.
  • Teams need to be motivated to mitigate risks as a longer term strategy
  • All actions, risks and issues must be quantified in terms of likelihood, impact and severity, focusing on high impact risks and aggregating exposure across the organisation.  While RAG status is useful, a 20% risk that the organisation will pay a £1M bill focuses the mind.
  • Make a chart that is easy to change and very visible, so the team cannot forget.
    • By clarifying risks to people in this way they become more aware of the need to reduce future possible events, which in turn reduces the number of issues.
    • Badly run programmes and projects have many rambling issues with actions day after day.
    • Prevention is better than cure!

Scope :  Fixed in the baseline, it arises from agreeing product quality and definition with stakeholders.  Strongly linked to cost, change management is the only adjustment process.  Creep is avoided through traceability and management of the 6 project parameters.

Benefits:   The balance of the benefits to cost is the major contribution to the business case, which determines the viability of the project.

Overall the business case (benefits, cost)  is tracked, scope and quality often stay fixed.  Reducing risks can accelerate time.  




The Programme Manager will support the Programme Office.  He will make sure that everybody is providing the PMO, with the right answers on time, to serve as a hub for project information for the business.  This is reinforced by a regular meeting.


Your decision whether to outsource will hinge on being confident that the quality, timescales, cost and risk will still be adequate.

  • Vendor selection, is an extra step in the project (selection, negotiation, contract management), which is still all about managing people, process, quality (time and cost), risk and change.
  • The selection criteria will be based on:
    • Creating an outsourced Service Management process that dovetails into all BAU processes.
    • Setting up KPIs to trigger financial penalties, which If they have not impacted the brand or P&L, consider recovery with improved performance.

Consider the:

  • Shape of the project
  • Understanding targets
  • Getting the contract right
  • Resource required
  • Alignment of the customer, suppliers, team and Board


With an agreed Portfolio, I switch my focus to completing the baselined plans. 

The engagement stage is about setting up the project towards agreeing a baseline, which is often the start of the fixed contract.

There are two entry points: 

  • If the project is the first step within the organisation, creating a contract will drive out the baseline documents
    • Business case – incl risks, plan AND alignment with organisational components (business plan, portfolio….
  • If the project is part of the continuous work, we are probably already embedded in the organisation.

Typically we seek to put a time and materials contract in place after we have done sufficient due diligence, with a health check, which varies in size, depending on the assignment.

My approach is to:

  • Work from the project target, using product based planning to a plan.
  • Present the high level baseline aligned across the organisation, identifying emerging risks and any alignment concerns.
  • Sponsor and PM will make sure they are ready for each step.
    • They need to agree the project scope and target, whilst their relationship is often at its infancy.
  • We will seek to understand the culture and politics (also considered at Strategy level).
  • Raise risks and issues.
  • Ensure that resources are available as build plan, covering all skill types
  • Complete baseline, blend in changes / direction from sponsor and re-discuss.  Repeat as few times as possible.
  • Agree to move to baseline and kick off.
    • Baseline dictates plan to deliver project target, wrapped in a contract

The art is to reflect the developing baseline at the right time to the stakeholders.  It is far easier to take a top down approach , through ensuring stakeholders understand :

  • Forecast P&L, Business plan, Vision, Strategy, Portfolio
  • Project scope and targets
  • Baseline components – Products, Plan, Risk, Quality, Project target

How do you manage delivery and vision expectations?

  1. Understand the real concerns of management, their true expectations, and any elasticity in the baseline deliverables and vision.
  1. Challenge the plan before baseline.
  1. Distil unknowns to a minimum

Action:  PM will check, measure and document any differences to expectations caused by:

  • Unclear vision
  • Inaccurate documentation of plan to meet vision
  • Failure to understand the plan
  • Clarity over targets set

How to

  • Align project with organisation
  • Set a baseline to track
  • Communicate a baseline
  • Manage viability, risk and plan
  • Give confidence
  • Prepare to mobilise

Creating baseline documents themselves is usually about putting the right information in a framework.  Templates for PIDs, risk logs, product backlogs etc are all available on the web and there is lots of software out there to help in tracking measurements and version control.


  • Create a baseline plan for Board / Sponsor approval that contains a forecast net benefits line.  Everyone is then in position to mobilise the plan.
  • A combination of benefits (tangible and intangible) and costs (forecast and actual), within a business case, will be used to track viability on an ongoing basis, and align progress to the roadmap to deliver the vision.
  • Measuring vision, roadmap, plan against risks allows me to recommend to the Sponsor the pace to take throughout the project.  Sponsor will need to set the appropriate pace (risk/reward ratio), primarily to meet his vision.
  • Setting up an estimating model will remove the disruption that changing estimates  bring.  Measuring actual time and cost against forecast, resource utilisation and pace of delivery during the course of the project, provides better control.  It will also feed the portfolio view to improve predictions for other projects across the organisation.
  • Keep project delivery aligned with Portfolio and Strategy, by providing a dashboard that will ensure that time, cost, quality, risk is measured against the roadmap to the vision.
  • Alignment of investment, strategy, portfolio, programme/project must be in spirit and not forced. Otherwise there is no buy in to the plan.

Baselining takes a snapshot of your first delivery plan – Gannt project plan, risks, business case (and often other aspects, such as – quality, communications strategies).  It provides the reference point to measure progress and deviation.

How do you set baselines?

Well run projects make management of the business and changes easier.  Sponsors, acting through Portfolio Management are able to adjust to the business needs of their market. With a clear baseline, it is easier to control any changes in the Portfolio during the project lifecycle.

Stakeholder Management on the same page

You must bring the Sponsor, Sponsoring Group, Programme and Project Teams onto a single aligned journey of truth for the programme. This means that the difference between peoples understanding on the programme is minimised.

  • Stakeholder management is about clear timely communication from both team and stakeholders, which creates the right relationships.
  • The danger of communicating on-the-fly is that, in your endeavour to “keep them happy”, you can give a slightly different steer from one stakeholder to another.
  • Stakeholders cannot sit on the edge of project activity.
  • They must be transparent to the team. 
  • To improve the stakeholder cohesion, it is better to spend more time on fine tuning the communication plan and conducting focused meetings to bring everyone together.  You can then reference back to the signed off baseline plans or change control.
  • Depending on the frequency of communication required, it is best to log every single piece of communication with everybody.
  • You may choose to communicate through an intranet environment, and re-enforce face-to-face, while keeping your script consistent with your plan.
  • Tools such as confluence and mindlink software make communication management easier.

The ideal is to try and do as much of the communication as possible with all the stakeholders together, through well planned meetings.  This will help the:

  • project teams to focus on delivery of their products
  • stakeholders to understand progress towards delivering the vision / benefits.

Create baseline documents

In many organizations change is difficult, because the demand is unclear and the mechanism for controlling the supply is weak. The baselined plan has delivery date estimates that in reality will be later than hoped.  Unrealistic timescales are made worse by gut estimates or management pressure.  Therefore inaccuracies in demand, supply along the timeline reduce precision.

Creating baseline documents themselves is usually about putting the right information in a framework.  Templates for PIDs, risk logs, product backlogs etc are all available on the web and there is lots of software out there to help in tracking measurements and version control.

TickCore assumptions, constraints, estimates etc are in a logical structure.

End to end steps

  1. Set Project Target and Scope
  2. Product breakdown structure or Product backlog (Epics, features…) – define quality
  3. Timeline or plan and set up estimating model
  4. Resource allocation
  5. Brainstormed risks at all levels to get buy in
  6. Baselined project plan

The key relationship – PM and Sponsor

  • tolerance with the sponsor, typically, time, cost, quality, risk (based on potential impact value – £)
  • contingency (say 5%)
  • notification of progress through weekly/fortnightly reports and immediately if tolerance or contingency are likely to be exceeded.

As Project Manager, I am always aware of tolerance, and will be up front to management immediately.  Early discussions avoid the difficult discussions, which can become personal and disruptive. The question “why are things going wrong?” is frequently raised too late

How does Tolerance and Management by exception work?

Delegation of a clear scope to a project manager, who flags difficulties through escalation is how it should work.

If you do’nt get it right

  • Sponsors typically manage or delve into the detail and disrupt.
  • Project Managers often fail to grasp the nettle

The extremes of this “balance of power” are:

  1. The project team executes tasks and reports them to management who make the decisions.  This is just like line management. The project team does not have the authority to make decisions.  They will not be committed, as they do not take part in the decision making.                                              NOT RECOMMENDED
  2. If management can be convinced to give the project team control and operate on tolerance
    • the project team are given responsibility for delivering the plan, providing they stay within the tolerance.

 Typically, I agree tolerances of time, cost (say 5-20%) and quality at 5%, on top of the contingency, which varies depending on factors such as risk.                                                                                                      RECOMMENDED

Normal conditions

I will manage the project within tolerance ie plan +/- X% and the sponsor is aware and confident that I will tell him if the tolerance moves above our agreed level(s).


To improve accuracy in the baseline:

  • Demand / Supply:  Ensure that the demand is well calculated and supply skills are matched correctly and balanced.  Review the components through each step (market sector size, your market share, mission, product quality)
  • Portfolio:  Ensure that project targets and scope are correct and align to other components in the organisation (ie business case, plan, forecast P&L)
  • Engagement:  It is all about alignment.
    • In particular stakeholders need to agree in spirit to the baseline or problems just surface later.

Kick off

Once the baseline documentation has been assembled, there is a kick off meet, which:

  • communicates a clear baseline position, from which we can monitor team progress.
  • establishes a delivery plan that the wider business wide team see progress against.
  • finalises the baseline status as version 1 of the documentation, covering initial RAID (Risk, Issue, Action, Dependencies) log, business case and plans.

The devil is often in the edges of process, technology and people.  Best practice is a crystal clear process from market to service acceptance, which meets the vision and will convert to continual profit in service. 

TickPost Kick off

Get the plan right, by walking it through with the whole team, at an open kick off meeting, ensuring the vision is aligned with the business case (plans and risk).  Success is tracked from then, with earned value being a simple, quick and easy way to keep stakeholder, sponsor, team and wider business aligned.

Reporting into Portfolio Management 

Effective management relies on a defined baseline for each project, programme, and service. This is tracked for all the projects.  We take a snapshot of the business case, plan, products, quality, cost, risk, tolerance, and contingency at appropriate times, so the Portfolio team can maintain alignment business wide.  Updates are provided to an agreed timetable.

TickPost Kick off

Without the discipline of setting up these projects correctly, a mist of uncertainty is created, where you just cannot see the status.

Especially with complex projects, you need to manage your carefully crafted plan.  All parameters, from risk to realisation need to be handled with care!  The more precision in your work the easier status is to manage.

Once baselined, we operate on tolerance in a controlled environment within defined stages. With planning and efficient management between Sponsors, Stakeholders, Project Manager and team, exceptions can even be avoided for difficult projects. Communication across the project and frequently across the Programme or Portfolio, keeps everyone on the road map to the vision.

Contract projects

The danger in contract projects is that the contractor takes a while to get up to speed on a project that has often lacked care.  Once ready to improve things, the project is in a worse state.  He may then be seen as the cause!

  • The change to this project comes when you have measured and recorded everything, set the ground rules and positioned everyone.
    • This reduces risks and issues and increases our likelihood for success.
  • Major changes to projects after the kick off can be disruptive, as teams will have to completely alter their mindset.
  • Nevertheless, sometimes business change forces it.

The “Planning Cycle”

This allows control through ironing out early problems.  Correct and careful planning ensures barriers can be easily removed on the day they arise.

How do you

  • Keep everyone focused?
  • Remove barriers and risks before they hit you?
  • Deal with change?
  • Keep to tolerance?
  • Energise the team?
  • Maintain Quality…

Mobilise and energise the team, using appropriate processes, to deliver in a timely, structured and controlled manner. Any changes to plan tracked using change control.

  • Run workshops that inform status and ensure that everyone knows their role in practice.  They are not discussion sessions.
  • Ensure the framework for the whole project is in place – contract, milestones, products, stages, requirements, Business Processes, plans, benefits realisation plans, configuration, correction logs and RAID…
  • continually assess any movement of the baseline plan (time, cost and quality), risks and change management log against the business case.  This provides a project heartbeat that tells everyone:
    • what we thought at baseline,
    • what has changed against target, and
    • whether it is within current tolerance.
  • Any planned changes, from baseline onwards will be made visible to all and tracked using change control.
  • Risks – review weekly in depth on the risk log (risk description, likelihood, severity and impact, with a quantified impact in financial terms, which are agreed with the sponsor – or suitable alternative).
    • The risk register will contain risks at different RAG level and value.
    • They are tracked and reported within the context of the agreed tolerance.  If the risk level is too high, I would suggest to the board / sponsors to consider increasing resource, descoping, lowering the pace.  All require careful thought.
  • Everybody gets it…so now make sure there is a feedback loop, so that you can correct as you go.



Make sure you still consider the Stakeholders and Sponsors

  • Ascertain whether the business / project can cope with the pace, or will it be dragged back by too high a risk level (or too many risks).  The risk level must satisfy the decision makers, but still motivate the project / programme team.
  • Decision- makers can receive frequent updates through the intranet (sharepoint, wiki, jira, confluence, other), manage by exception and make authorized changes through change control.

Replan if Tolerance Exceeded

  • During the delivery stage, targets are continually measured and reinforced by exception, alongside any  changes that arise, with all parties, keeping them aligned or realigned to the project target and overall vision.
  • The PM controls the whole of delivery from baseline through to completion.
  • Unless tolerance is exceeded

If tolerance is exceeded, sponsors (possibly with stakeholders) may enforce exception planning.

The sponsor and myself will discuss and create a new plan.

  • Typically it is a watershed moment that leads to a clarification of targets, review of options and commitment to a realistic outcome.
  • From experience I try to avoid a knee jerk reaction
  • The fortnightly checkpoint report will indicate progress against plan and will flag issues prior to tolerance being exceeded.

Quality is the watch word for Projects

Many projects omit this word.  It is difficult to define, often badly understood, and too frequently ignored.

  • Project activities never flow exactly as planned, although time, cost and quality need to be delivered to targets.
  • All products need to meet the level of quality, defined in the quality plan.
  • Imperfect deliverables are often spotted too late, in transition, service or business change!  Time is merely then taken in service rather than during delivery, hitting quality and profit!.
  • Make sure testing is sufficient and products fit the business and style required.

Deliverables sign off

The honest team finds this stage easy.  More political cultures, getting to proper sign off with clear accountability can be a real challenge.

  • Service transition needs to be managed carefully, with clear visibility, appropriate accountability, lessons learnt and roll back plans.
  • The backlog and/or planned deliverables need to be reviewed by Service transition and management team and mapped directly to the architectural vision, prior to transition.
  • The final fortnight is about completing and finishing, so use a completer finisher!
  • Any gaps will lead to busy sprints or heightened project activity toward the deadline. Well planned transitions avoid this.


About the Author