The Project Workout Community Site

0dc7f87a-943c-41ea-9285-1c83082207dc
Diagram

Project Workout Community

How to use this site

Terms and conditions

Project Workout Community

Welcome to our community and the resources zone. This page provides you with quick links to areas of the Community library, Project Workout Method reference site and associated knowledge bank.

Here you will find a lot of resources to supplement the book, including articles, a blog, frequently asked questions and, most importantly, an interactive Project Workout Method, showing you how everything fits together.

Principles

Get the basic principles right and the rest follows. If the "rules" don't make sense, then go back to these to see where you might be going wrong.

References

Articles

A number of articles on portfolio, programme and project management.

References

Frequently asked questions

Here are a number of the questions I have been asked with answers and references to where you can learn more.

References

Useful links

The wealth of good quality information on the internet expands every day. Here are a few references you migh find useful.

References

Cartoons

Sometimes a picture saves a thousand words. Here are a number of the cartoons from "The Project Workout" to either entertain or inform you.

References

The Project Workout Method

The Project Workout's method, its activities, roles, RACI, deliverables and guidance.

It's an example of how you could publish your own method in your organisation.

References

The Blog

The Project Workout Blog, including lots of mini artickes and discussions which you can comment on and add your own views.

Links:

Video on the project framework

A short video in which Robert Buttrick talks you through the project framework. After looking at this, why not have a browse through the Project Workout Method yourself?

Briefings:

Video on SaleForce APP for Project Workout

A short video in which Rober Buttrick talks you through the SalewsForce App developed to support the Project Workout.

Briefings:

Project Workout web site

Link to the main web site for The Project Workout

Links:

Standards

Standards - love them or hate them, they are here to stay, so why not use them to your advantage? This section tells you about the various standards and how the Project Workout measures up to them.

References

Robert Buttrick

It is my vision to see organisations (both public and private) thrive through directing and managing their futures using effective, business led project and programme management techniques. I foresee a time when:

  1. all significant change is directed and managed cross-functionally, harnessing people and resources from across and outside the organisation;
  2. people find it second nature to form and perform in multidisciplinary project teams, focussed on achieving business benefits;
  3. project skills and knowledge is a core capability of ALL managers and top executives.

I believe the best way to achieve this goal is to work with people, helping them to help themselves, ensuring they understand the practices and can carry them forward themselves.

Links:

Welcome to the community. These pages provides you with quick links to a lot of resources to supplement the book, including articles, a blog, frequently asked questions and, most importantly, an interactive Project Workout Method, showing you how everything fits together.

Sign in to access the full content

To see the full set of templates and guides you need to register.

References

How to use this site

Using the site

Some people like reading of a screen and clicking around. Others like to read a book or a document.
Both these needs are covered in this community web site.

Hovering over any item, gives you a prview of what it's about

  • Clicking on any item will bring up more detail, together with any relevant links.
  • Clicking a link will enable you to
  • download a resource
  • open up more information
  • pass you to another web site.

Usually new material opens up in a new tab. If you want to go straight to the next page, in the same tab, simply click on the "down-arrow" icon at the bottom right of the relevant items.

In most views, you can make the margins wider or narrower.

Thje Index panel can be collapsed or expanded using the "+" or "-" . It also includes a "Find" feature.

If you see "Open as a pdf", you'll be able to download the web content as a convenient document.

Commenting

Where ever you see a speech bubble, you can add a comment or a question (registered users only - see below), which will be repied to on the forum either by Robert or any of the other registered users. This is a great feature for any organisatiion's "method" as commenting can be very precise and easy; if it isn't easy, people won't provide feedback and your own method won't improve.

Registering

We provide you with tiered levels of membership to our community based on the amount of content that you are able to access. We are currently offering Registered Users access to view the community free of charge.

To login or register please click on the 'Sign In' link to the top right of the screen and follow the process.

To use and adapt the "Project Workout Method" for use in your organisation, please email inquiries@businessoptix.com.

Terms and conditions

All parts of the site represent extracts from The Project Workout an have all  rights reserved; no part of this web site may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, photocopying, recording or otherwise without either proir written permission or a licence permitting restricted copying issued in the United Kingdom by the Copyright Licencing Agency Ltd.

If you want to use any of this material commercially, please obtain permission.

Links:

A few words on terminology

In the Project Workout I refer to STAGES and GATES as convenient descriptions for the periods when work is done and for the points in time when a check is made on the project prior to starting the next stage. Terminology often found in practice also includes:

  • For stage: Phase;
  • For gate: Tollgate; Gateway; Quality Gate; Checkpoint; Assessment; Review

In this book, I reserve the use of the word “phase” to describe a project that is to be introduced or built with benefits designed to arrive in different time frames. For example, major roads projects are frequently introduced in phases so motorists can benefit from the first 20 miles built and do not have to wait for the full 80-mile stretch to be completed. Each phase is in fact a project in its own right and comprises a number of stages.

The word “program” is also problematic, much used and abused to the extent that it is often meaningless. For example I had a job title of “program manager,” but I did not use it on my business cards as it did not tell anyone what I did; indeed it might even have misled them. Programs are discussed more fully in Chapter 13 as a tightly aligned and tightly coupled set of projects. Note this does not conflict with the emerging view that programmes include the period of benefits realization, as in projet Worout, all project are business and benefit led.

The word “program” is frequently used to bundle any projects together for the convenience of reporting, planning, or other management purpose. In this book I refer to these as a “portfolio.” This is discussed further in Chapter 14 in relation to what I term “business programs.” Just to keep you on your toes, “portfolio” can also refer to bundles of programs as well as projects

In hierarchical terms the relationship is:

  • the organization’s portfolio(s) of programmes and projects;
  • program;
  • project;
  • stage.

The above terms can look confusing, mainly because there is no universal definition for them. Each organization (or standards body) will choose its own definitions. The point therefore is for you, in your organization, to choose what suitsm visibly define the terms and use them consistently.

A

Accountability

What you can count on a person doing. That person and only that person can be called to account if something they have accountability for is not done.

Activity

Individual components of work that must be undertaken to complete the stages of the project. Each activity should be defined in terms of its start and end dates and the name of the person accountable for its completion.

Approval

The term used when an individual accepts a deliverable as fit for purpose such that the project can continue.

Assumption

An assumption is made when an unknown is taken to be a fact. Assumptions can be tested using sensitivity analysis and often pose a risk to a project.

Authorisation

The decision which triggers the allocation of the resources funding and needed to carry on the project and provide the project sponsor and project manager with the authority to undertake the project or the part of the project which has been authorized.

B

Backcasting

Using the desired end result of a project as the principle basis and starting point for planning so that planning is initially conducted working backwards from project completion.

Bar chart

Graphical representation of activities within a project over time. Each activity’s duration is shown as a bar, the ends of which correspond to the start and end dates. A bar chart is also known as a Gantt chart.

Baseline

The project plan you use to track progress against during a project. The baseline plan includes, start and finish dates of activities, resources, scope and costs. The baseline cost is often called a project budget.

Blueprint

A description of the “future business or organisation,” its working practices and processes, the information it requires and the technology that will be needed. This term is usually used in the context of (business) program management.

Brainstorming

A technique for generating ideas in a group.

Budget

Planned, approved cost for the project. See also baseline.

Business case

A document providing the justification for undertaking (or for continuing) a project, defining the financial and other benefits which the project is expected to deliver together with the schedule and other constraints within which the project is to operate. This is usually prepared in two stages. The first is the initial business case which is prepared for the Detailed Investigation Gate review. The second is the full business case which is prepared for the Development Gate review.

Business programme

A Business Program comprises current benefit generating business activities together with a loosely coupled but tightly aligned portfolio of programs and projects, aimed at realizing the benefits of part of a business plan or strategy.

Business programme office

A support office, which supports the roles of the Business Programme Sponsor and Manager.

Business programme plan

A part of the organization’s business plan which focusses on the targets (benefits) and resources of a particular business programme.

C

Capabilities

Building blocks of systems, process and competence which are combined with other capabilities to provide an organization with operational potential.

Capacity buffer

A Critical Chain term. Protective time placed between projects within the drum resource.

Change control

The formal process through which changes to the project plan are introduced and approved. Changes are recorded on a change log. (Do not confuse with the management of change.)

Closure (project closure)

Formal “end point” of a project either because it is completed or because it has been terminated early. Closure is formally documented in a closure report

Condition of satisfaction

Conditions, which if met, enable one to objectively declare a project a success. These should be indicative of benefits realization. Recognition EventsTM and Value FlashpointsTM are special types of condition, used in the Isochron methodology.

Configuration management

A discipline, normally supported by software tools, which gives management precise control over the deliverables of a project (or components of an operational environment) and ensures that the correct version of each part of a system is known and documented.

Constratint

Defined restriction or limitation imposed on a project or operational work.

Contingency plan

An alternative plan of action which should be followed in the event of a risk occurring.

Cost plan

Document detailing items of cost associated with a project, in categories (work packages) relating to the schedule plan. See also budget and baseline.

Critical chain

The critical chain of a single project is the sequence of dependent events that prevents the project from being completed in a shorter interval, given finite resources.

Critical path

The path through a series of activities, taking into account dependencies, in which late completion of activities will have an impact on the project end date, or delay a key milestone.

Critical success factor

Factors that will ensure achievement of success criteria. Note: success criteria are criteria to be used for judging if the project is successful (see conditions of satisfaction).

Culture

  1. The norms and behaviors of a group (the way we do things here!)
  2. Unconscious programming of the mind leading to a set of similar collective habits, behaviors and mindsets.

D

Deliverable

Output produced by the project in the process of achieving the business objectives, e.g. a report, system or product. Each key deliverable should be defined in the project definition section of the business case document and represented by a milestone on the project plan. Alternative words are “product”, “work product” and “output”.

Dependency

A constraint on the sequence and timing of activities in a project. Activities may be dependent on other activities within the same project (internal dependency) or on activities/deliverables from other projects (interdependency).

Detailed investigation stage

The second stage within the project framework when a feasibility study is undertaken to choose the best solution and when that solution is defined in sufficient detail for delivery to start.

Detailed plan

Developed throughout the project, from the summary plan, breaking down the forthcoming stage into manageable work packages and activities.

Duration

The amount of time required to complete an activity. It is calculated as the finish date – the start date.

E

Earned value

  1. A management technique which analyzes project progress by comparing the actual money or hours (or other measure) planned with the value of the work achieved (measured on the same basis) and the amount actually spent. Mostly used on contractor-based projects.
  2. A method for integrating scope, schedule and resources and for measuring project performance. It compares the amount of work which was planned with what was actually earned with what was actually spent to determine if cost and schedule performance are as planned (PMI).

Effective

Successful at realizing an objective.

Efficient

Providing progress or performance with minimal waste of resources.

Emergency project

A project which is required as a result of a business issue which will severely damage the organization if not addressed without delay. These projects may cause previously committed projects to be allocated a lower priority or to be terminated in order to release resources.

Escalation

To increase the awareness and ownership of a problem or issue to a level in the organization where the required resources, expertise and/or authority can be applied in order to resolve that issue.

F

Feeder buffer

A feeder buffer protects the start of a Critical chain activity from a delay of an upstream dependent non-critical chain activity. A project can have many feeder buffers.

Fog project

Formally known as an open project, this type of project occurs when you are unsure of both what is to be done and how.

G

Gate

The decision point, preceding each stage, at which all new information converges and which serves for:

  • quality control checks
  • prioritization
  • quality control checks
  • prioritization

H

Healthcheck

A tool used in project reviews to assess the overall risk associated with the project.

I

Idea

A possibility for a new or enhanced capability, system, service, or product. This is written up as a proposal.

Impact

The influence one thing has on another, with respect to how changes in one bring about changes in the other.

Impact asessemnt

A study undertaken to determine the effect of an issue on the project. An impact assessment is required as part of change control.

Interdependency

If Project B requires a deliverable from Project A in order to achieve its objective, project B is dependent on project A. Dependency is when a deliverable is passed from one project to another.

Internal rate of return (IRR)

The discount rate at which the value of the opportunity will be zero. Note that in concept, the principle is that the higher the IRR, the “better” the opportunity. However, this guideline should be used with caution.

Issue

A circumstance (event, lack of knowledge, etc.) that has occurred and which will affect the success of a project. They are recorded on an issues log. An issue can either be resolved within the project as defined or a change may be required to accommodate it.

L

Late activity

An activity which is forecast to end later than the baseline plan finish date. This is reported on a late activities report.

Life cycle (project lifecycle)

A sequence of defined stages over the full duration of a project, i.e. initial investigation, detailed investigation, develop and test, trial, release.

Link

A relationship between dependent activities.

M

Management of change

A name often used to describe the process of transforming and organization from one state to another. Not to be confused with change management which is a technique used on projects to ensure that alterations to the project time, scope, benefits and cost are introduced in a regularized way.

Milestone

A major event (often representing the start of a stage) which is used to monitor progress at a summary level. Milestones are activities of zero duration.

Movie project

Formally a semi-open project, where the means are known but not the output.

N

Net present value (NPV)

The value calculated by projecting the future cash flow and discounting the value of future years’ cash at the discount rate to give its notional value today.

Network chart

A diagram which shows dependencies between project activities. Activities are represented as boxes or nodes and the activity relationship is shown by arrows connecting the nodes. Often called a PERT chart.

O

Opportunity

The opposite of a risk. An opportunity is a possibility to enhance the project benefits. Opportunities are recorded on an opportunity log.

Originator

The person who conceives an “idea” or need for a new development or enhancement and publishes it in the form of a proposal. This person can come from any function or level in the organization.

Output defintion document

The fundamental sourcebook describing the project output in terms of “feel,” technology, commercial and customer/user needs. It is the document which integrates all the individual system, process and platform requirements and specifies how they will work together.

P

Phase

A phase is a single project within a phased programme of projects (hence phase 1 project, phase 2 project, etc.). Note the PMI definition of “phase” equates to the Project Workout definition for “stage.”

Pilot

A pilot is the ultimate form of testing a new development and its implementation plan prior to committing to the full release. It is undertaken using a sample of potential customers and users. This would normally take place in the trial stage although may, in some cases, be treated as a limited release.

Portfolio

A grouping or bundle of programmes and/or projects which are collected together for management convenience.

Portfolio management

This is a process that aligns a portfolio of projects to the strategy of the organization. As such, it is an integral part of business planning. It should enable an organization to select those projects which will create the greatest value for the organization, taking into account risk, strategic balance and constraints.

Post implementation review (PIR)

A review, three to six months after the end of the project, to assess whether the expected benefits and performance measures are being achieved. This checks the effectiveness of a project as opposed its efficiency which is reviewed as part of project closure.

Programme

Programs are a tightly coupled and tightly aligned grouping of projects.

Progress report

Regular report from the project manager to the project sponsor and other stakeholders summarizing the progress of a project including key events, milestones not achieved and issues.

Product

A term used in some project methods in place of deliverable. Hence the terms “product breakdown structure,” which identifies, in a hierarchical way, the deliverable/products which are required and “product flow diagram,” which identifies each deliverable’s derivation and the dependencies between them.

Project

A project, in a business environment, is:

  • a finite piece of work (i.e. it has a beginning and an end) undertaken in stages:
  • within defined cost and time constraints;
  • directed at achieving a stated business benefit.

Project board

Body established to monitor the project and to assist the project sponsor in delivering the benefits and the project manager in achieving the deliverables. Sometimes called a steering group or steering board.

Project buffer

The project buffer protects the project end date from viability in the duration of the tasks in the critical chain. For a single project the size of the buffer depends on the number and duration of the critical chain activities and on the degree of risk associated with each. See also feeding buffers.

Project definition

A section within the Initial and full business case which defines a project, i.e. what will be done, how it will be delivered and what business need the project supports.

Project manager

Person accountable for managing a project on a day-to-day basis, from start to finish, to ensure successful implementation within agreed cost, schedule and quality targets.

Project plan

The supporting detail to the project definition which details the schedule, resource and costs for the project. It can be in outline or detail.

Project portfolio

A grouping or bundle of projects which are collected together for management convenience, e.g. the collection of projects sponsored by an individual is his or her sponsorship portfolio; those project managed by a person is a management portfolio; the full set of projects within a organization is the organization portfolio.

Project review group

The term used in this book for the body accountable for the project authorization process. There is no industry standard for this.

Project sponsor

The person who sees a commercial possibility in an idea and who agrees to take ownership of the proposal. Once a project is approved, the project sponsor is accountable for realizing the benefits to the business.

Project support office (PSO)

A group set up to provide certain administrative and other services to the project manager and team. Sometimes a PSO provides its services to many projects in parallel. See also support office.

Proposal

A short document prepared, by the originator, for the initial investigation gate review, which outlines the proposed project, its fit with current strategy and, if known, the impact on the organization, broad estimates of benefits and cost and expected time to completion.

Q

Quality

The totality of features and characteristics of a deliverable that bear on its ability to satisfy stated and implied needs. Also defined as “fitness for purpose” or “conforms to requirements.” Hence “quality criteria” are the conditions which a deliverable must meet in order to be accepted as fit for purpose.

Qulaity plan

A document defining the quality policies that will be applied on a project. Hence “quality planning” is determining which quality standards are necessary and how to apply them.

Quality review

A review of a deliverable against an established set of quality criteria.

Quest project

Quest projects are formally known as semi-closed projects. You are clear what is to be done but have no idea about how to do it.

R

RAG (Red; Amber; Green)

A simple status reporting method, enabling the reader of a report to grasp very quickly whether a project is likely to achieve its objectives. RAG stands for Red–Amber–Green.

  • Red means there are significant issues with the project that the project team and project sponsor are unable to address.
  • Amber means there are problems with the project but the team has them under control.
  • Green means that the project is going well with no significant issues, although it may be late or forecast to overspend.

The RAG status is usually based on the project manager’s own assessment of the situation and is useful for highlighting those projects which may have difficulties. Some organizations also have RAG status set automatically by systems, e.g. when a project is forecast to overspend.

Sometimes people use "BRAG", where the B denotes "blue" for completed.

Ready for service (RFS)

The milestone prior to the release stage, by when all prerequisite project work, testing and trials have been completed and full operational support is in place.

Recognition event

A real life happening that when it occurs tells a sponsor and other stakeholders that one particular expectation of the project plan has been met. This is a term used in the Isochron method. See also Conditions of satisfaction.

Recognition Event is a Trade Mark of Isochron Ltd.

Release

Generic term used to denote when an output from a project is put into service, e.g. a product can be used by a customer under standard terms and conditions (i.e. not trial agreement), handover of a customized service for the customer to start using, a system started to be used, new process operational. It must not be confused with ready for service which is the point when all capabilities are ready to use but have not yet been put to use.

Risk

Potential occurrence or uncertainty that would jeopardize the success of a project. These can be split into business risks, which impact benefits realization and project risks, which impact project delivery. Risks should be recorded on a risk log, continuously assessed and mitigation action taken.

S

Simple project

A project where the end point can be seen clearly from the detailed investigation gate. Typically simple projects consume little resource or have their own separate resources which cannot be allocated to other projects.

Single point accountability

The concept that any activity, or work package, at any level in the work breakdown structure has only one, named person accountable for it.

Slippage

See late activities.

Sponsor

See project sponsor.

Stakeholder

Any person or group who has an interest in the project or its outcome. Typically some support it, some are neutral and other are antagonists.

Stakeholder influence map

A diagram used to depict the influence that individual stakeholders have on others. The objective is to identify the routes by which key influencers and decision makers can be enrolled in the project’s objectives.

Sub-project

A tightly aligned and tightly coupled part of a project. Subprojects are usually run to their own staged life cycle.

Success

A successful project is one which achieves its business objectives and realizes the expected benefits. It may be that it is also delivered within the defined time, cost and quality constraints but in the “real world” that is not always essential. Success is formally measured using conditions of satisfaction; however, different stakeholders will have their own views on whether a project is successful, regardless of this.

Summary plan

Initial part of the evolution of the schedule, resource and cost plan, developed at the start of the project, defining the overall targets and key dates.

Support office

A group of people providing administrative and/or specialist services to defined roles in the project management environment. Hence project support office and business programme office.

T

Termination

The premature closure of a project due to an issue which cannot be addressed or because the risks have become too high.

Theory of constraints

The theory expounded by Eli Goldratt which led to the development of critical chain schedule management.

Trial stage

A trial of a capability in same environment as the customer or user will use it. Often denoted as a beta trial under special trial agreements.

V

Value driver

The things which increase revenue or decrease cost or increase asset value in the organization.

Value flashpoint

A recognition event at which a particular project cash bebefit starts to be realized. In the Isochron method, value flashpoints are used to map financial implications of the project to the organization’s accounts and ties all project activity and investment to the points where benefits start. See also Conditions of Satidfaction.

Value flashpoint is a Trade Mark of Isochron Ltd.

Value management

A technique and process used in the investigative stages of a project for ensuring that deliverables are clearly defined and matched to business needs and that solutions represent value for money whilst remaining fit for their intended purpose. Do not confuse this with earned value.

W

White space

Unassigned resources which are available to work on future projects. White space is required at short notice for initial investigations and at medium notice to resource future projects after the detailed investigation gate. Without white space, organizations are unable to change themselves without taking resource from previously authorized and committed work.

Workbreakdown structure

A structured hierarchy of work packages.

Work package

Generic term used to describe a grouping of activities, stages, etc. each of which has a defined scope, timescale, cost and a single person accountable for it.

Project Workout roles

The Project Workout includes a number of role defintions. You can find these in the Project Workout Method.

References

Links:

Business programme roles

Business Strategy & Planning Board

The Business Strategy and Planning Board is accountable to the Chief Executive Officer for setting business strategy, directing corporate change and ensuring the business programmes realise the benefits required.

  • Sets strategic direction, policy and priorities.
  • Sets business and benefits realisation objectives and constraints for the organisation as a whole and for key elements of each Business Programme to ensure maximum benefits and progress toward the strategic vision.
  • Allocates funding and resources to each Business Programme function, through the approval of the business plan and each Business Programme Plan within it.
  • Monitors and reviews benefits realisation, delivery and costs from all Business Programme directing corrective action where appropriate.

Project Review Group

A cross-functional (or cross-process) group of decision makers for authorisation, prioritisation, issues escalation and resource allocation.

Its primary aim is to keep the pipeline of projects flowing. As such the project review group is the gate keeper for all the project framework gates and accountable as owner of the authorisation process. It may delegate gating authority to other roles as it sees fit.

The project review group exists to manage and communicate the authorisation, prioritisation, planning and pre-launch implementation planning for business change projects. This includes ensuring that fully resourced and committed plans for projects are created and aligned within the organisation’s rolling forecast and each has a viable business case.

The accountabilities of the group are:

  • to authorise projects and oversee any delegation of such authority;
  • to ensure that the portfolio can be delivered within existing funding allocations by ensuring the organisation’s business plan reflects the projects within the portfolio;
  • to ensure each project is locked in and committed to by those required to develop it and operate the outputs post-release;
  • to identify options for resolution of issues involving resources and escalate for resolution if appropriate;
  • to ensure that functions have planned in ‘white space’ resources to undertake initial investigations;
  • to communicate/publish the current status of the organisation‘s portfolio;
  • to act as the change control point for the organisation’s portfolio;
  • to be the owner of the authorisation process.

Business Programme Sponsor

The Business Programme Sponsor is accountable to the Business Strategy and Planning Board for directing the Business Programme, ensuring that the portfolio of projects and activities (Business Programme) within his/her scope realises the required benefits.

  • Provides business direction to the Business Programme in terms of making decisions, initiating new projects, terminating unwanted projects and resolving issues.
  • Approves the Business Programmes Plan prior to authorization by higher authority
  • Ensures that the combined benefits for the Business Programme are realized
  • Ensures the scope of the Business Programme covers the needs of the business
  • Directs priorities between contending projects and activities within the Business Programme.

Business Programme Manager

The Business Programme Manager is accountable to the Business Programme. Sponsor for day-today management of the Business Programme ensuring that the portfolio is planned and managed to ensure maximum focus and speed of benefit realisation.

  • Prepares and maintains a plan of scope, timescale, benefits and costs for the business rogramme including reserve for as yet unidentified projects and activities.
  • Selects and manages the portfolio of projects within the Business Programme to realise the required benefits and to ensure that the contributions of all parts of the organisation are taken into account.\
  • Approves and authorises projects as delegated.
  • Monitors performance against the Business Programme Plan, initiating corrective action and ensuring the integrity of the plan (including interdependencies).
  • Provides regular progress reports to the Business Programme Sponsor and senior management.
  • Ensures use of best practice methods and organisation procedures.
  • Assigns the project sponsor role for each project within the Business Programme.
  • Ensures the projects are progressed, by the project sponsor, through the authorisation process.

Project management roles

Project Sponsor

The Project Sponsor is accountable for realising the benefits to the organisation. This is an active role and includes ensuring the project always makes sound business sense, involving all benefitting units (using a project board if appropriate), owning the business case and making decisions or recommendations at critical points in the project's life. The project sponsor is usually a director, executive, or senior manager.

The project sponsor is accountable for realising the benefits for the organisation. He/she will:

  • ensure a real business need is being addressed by the project
  • define and communicate the business objectives in a concise and unambiguous way
  • ensure the project remains a viable business proposition
  • initiate project reviews
  • ensure the delivered solution matches the needs of the business
  • represent the business in key project decisions
  • approve key project deliverables and project closure
  • resolve project issues that are outside the control of the project manager
  • chair the project board (if one is required)
  • appoint the project manager and facilitate the appointment of team members
  • engage and manage key stakeholders.

Project Board

A Project Board is usually required for projects which span a number of processes or functional boundaries and/or where the benefits are directed to more than one market segment or function. If no project board is required, the role can be undertaken by a programme board or management team. A progamme board has accountability for a set of closely aligned projects. It is the project sponsor's responsibility as chair of the group, to keep board members focused on the key aspects of the project where their experience can be used to best effect.

The role of the project board (if required) is to support the project sponsor in realising the project benefits and in particular:

  • To monitor the project progress and ensure that the interests of the organisation are best served
  • To provide a forum for taking strategic, cross-functional decisions, removing obstacles and for resolving issues.

Project Manager

The Project Manager is accountable to the project sponsor for the day-to-clay management of the project involving the project team across all necessary functions.  Depending on the size of the project, the project manager may be supported by a project administrator, or office support team.

  • The project manager is accountable for managing the project on a day-to-day basis. He/she will:
  • assemble the project team, with the agreement of appropriate line managers
  • prepare the business case, project definition and detailed plans
  • define the accountabilities, work scope and targets for each team member
  • monitor and manage project progress
  • monitor and manage risk and opportunities
  • manage the resolution of project issuesmanage the scope of the project and control changes
  • forecast likely business benefits
  • deliver the project deliverables on time, to budget, at agreed quality
  • monitor and manage supplier performance
  • communicate with stakeholders
  • manage the closure of the project.

Gate decision maker

Person or body with the authority to make a go-No go decision at a gate as defined in the Business Case. Typically the decision maker will be either:

  • Project Review Group
  • Business programme manager
  • Project sponsor.

Team roles

Team manager(s)

A team manager is accountable to the project manager. The role of a team manager is accountable for directing and supervising the individual members of the team and specifically:

  • be accountable for such work packages and deliverables as are delegated to them by the project manager,
  • ensuring they are completed on time and to budget
  • liaise and work with other team managers and members in the carrying out of their work
  • contribute to and review key project documentation
  • monitor and manage progress on their delegated work scope
  • manage the resolution of issues, escalating any which they can not deal with to the project manager
  • monitor changes to their work scope, informing the project manager of any which require approval
  • monitor risk associated with their work scope
  • be responsible for advising the appropriate team managers and/or project manager of potential issues, risk or opportunities they have noticed.

Team members

Team members are accountable to the respective team manager. The role of team members is to:
be accountable for such deliverables as are delegated to them by the project manager, ensuring they are completed on time and to budget

  • liaise and work with other team managers and members in the carrying out of their work
  • contribute to and review key project documentation
  • monitor and manage progress on their delegated work scope
  • manage the resolution of issues, escalating any which they can not deal with to the project manager
  • monitor changes to their work scope, informing the project manager of any which require approval
  • monitor risk associated with their work scope
  • be responsible for advising the appropriate team managers and/or project manager of potential issues, risk or opportunities they have noticed.

Enterprise project management roles

Programme Management Design Authority

The Programme Management Design Authority is accountable to the Programme Management Director for acting as guardian for the organisation's 'best practice' methodology, processes, tools, systems and templates for authorising and undertaking programmes and projects.

  • Updating, supporting and obtaining user feedback (including lessons learned) on the project environment and future developments
  • Developing and communicating changes to the environment
  • Ensuring that the staged project management framework and associated project controls are in place and used throughout the organisation
  • Preparing and leading briefings on the frameworks and their use
  • Ensuring there is a consistent and complete range of project management training and development programmes available
  • Ensuring consistent recruitment and selection tools and processes are available for project management related appointments
  • Ensuring that the project processes interface at a high level with other core processes within the organisation
  • Providing consulting, coaching and facilitation to users of the project framework.

Programme Management Director

The Programme Management Director is accountable to the chief executive officer for ensuring that all business change is planned, directed and managed in an effective and efficient way using appropriate programme, and project management techniques.

  • Championing good value business programme and project management nd a benefits-driven culture
  • Introducing, maintaining and improving common programme management framework, process and methods,
  • including for business planning, project selection and project authorisation.
  • Creating an environment in which business programme and project managers and teams are developed and recognised for their skillsCreating an environment in which business programme and project managers and teams are developed and recognised for their skills
  • Recommending changes to senior management to improve the effectiveness and efficiency for delivering business change
  • Providing independent reviews of projects

Other roles

Project coach

The project coach or facilitator is accountable for supporting the project manager, project sponsor and project board. This may be by pure coaching or by giving advice, facilitation and guidance on project management. Both approaches will help project teams, both experienced and inexperienced, to perform beyond their own expectations. It is a role which is found infrequently but one which can prove extremely effective. Remember, in business-oriented projects the participants are likely not to be fully trained and capable project managers. They need to have someone who can give them the confidence to work in a way which may be alien to them.

Project support

Project support provides support and administrative services to the project manager on activities such as filing, planning, projectmonitoring and control. The provision of project support on a formal basis is optional. Tasks need to be done by the project manager or delegated to a separate body/person and this will be driven by the needs of the individual project and project manager. Project support could be in the form of advice on project management tools, guidance, administrative services such as filing and the collection of actuals, to one or more related projects.Where set up as an official body, project support can act as a repository for lessons learned and a central source of expertise in specialist support tools.

Specific responsibilities may include the following:

  • set up and maintain project files;
  • establish document control procedures on the project;
  • compile, copy and distribute all project management deliverables;
  • collect actuals data and forecasts;
  • update plans;
  • assist with the compilation of reports;
  • administer the document review process;
  • administer project meetings;
  • monitor and administer risks, issues, changes and defects;
  • provide specialist knowledge (for example estimating, risk management);
  • provide specialist tool expertise (for example planning and control tools, risk analysis).

Stakeholder(s)

Any individual, group or organisation that can affect, be affected by, or perceive itself to be affected by, a programme or a project.

ISO

Integration

The integration subject group includes the processes required to identify, define, combine, unify, coordinate, control and close the various activities and processes related to the project.

Stakeholder

The stakeholder subject group includes the processes required to identify and manage the project sponsor, customers and other stakeholders.

Scope

The scope subject group includes the processes required to identify and define the work and deliverables, and only the work and deliverables required.

Resources

The resource subject group includes the processes required to identify and acquire adequate project resources such as people, facilities, equipment, materials, infrastructure and tools.

Time

The time subject group includes the processes required to schedule the project activities and to monitor progress to control the schedule.

Cost

The cost subject group includes the processes required to develop the budget and to monitor progress to control costs.

Risk

The risk subject group includes the processes required to identify and manage threats and opportunities.

Quality

The quality subject group includes the processes required to plan and establish quality assurance and control.

Procurement

The procurement subject group includes the processes required to plan and acquire products, services or results, and to manage supplier relationships.

Communication

The communication subject group includes the processes required to plan, manage and distribute information relevant to the project.

External to project

Project workout guides and workouts

The guides and workouts are advice and techniques taken from the book and put in the context of the lifecycle and processes. You can find these in the Project Workout Method.

References

Links:

Guide to setting up a project

There are five key steps activities for you to follow undertake when setting up a project:

  • Set up the project team.
  • Prepare a project definition and business case.
  • Prepare a project plan.
  • Define your project organization.
  • Engage your stakeholders.

The purpose of formally setting up the project is for you to state explicitly the business drivers, scope, and and objectives for the project, that is:

  • why you are doing it;
  • what you will produce;
  • when you will produce it;
  • how you will approach the project;
  • who will be involved;
  • how much it will cost and benefit you.

This information is gathered in a document set (the Initial Business Case) andwhich, together with the associated plans, provides you with the starting point (baseline) on which all subsequent project decisions will be taken and against which you can measure project performance. Different organizations and methods have different sets of documents to support this, the common ones being:

  • Project Initiation Document (PRINCE2)
  • Project Definition
  • Project Management Plan  (APM, PMBoK)
  • Business case.

All these mostly contain the same information, it is just the way they are assembled and named which changes. For example, the Project Management Plan is often comprised of a subsidiary set of documents defining how each aspect of the project is managed, for example, risk management plan, schedule management plan. Some organizations combine the “business case”, which justifies why you are dong a project and proves its viability, with the “definition”, which defines the scope, schedule and costs.The reason for this is simple to ensure the two documents align as there is often a degree of duplication.  In the Project Workout, I have assumed a the business cases and the project definition are combined in a single document, called a “business case”.

For more information see Chapter 19 of the Project Workout.

Guide to setting up the team

Project teams are:

  • short term, being established only for the duration of the project;
  • cross-functional, to provide the necessary skill mix;
  • frequently part time, with team members fulfilling line and project tasks.

Bearing this in mind, it is essential that you agree the project roles from the start (e.g. project sponsor, project manager and project board membership) with the individuals concerned and their line managers (if appropriate). As many of the team members are likely to be part time and have other daily duties to attend to, it is essential that you agree with their line managers what their commitments are and how you should handle changes to this. The line managers may also have a quality assurance role to undertake, if so this must be agreed. If necessary, write and agree a role description, defining the individual’s accountabilities. Even if these descriptions are never referred to again, the act of creating them with the individuals, and and agreeing them, will clarify each person’s role and ensure there are no fewer misunderstandings. Finally, do ensure that accountability for any activity or work package on the project rests with a single person only. Shared accountabilties do not work; they lead to omission, duplication, and and confusion.

For more information see Chapter 19 of the Project Workout.

Guide to preparing a project definition

The project definition section of the initial business case document, defines your project – why you are doing it, what you will produce, and and how you will go about it.

For more information see Chapter 19 of the Project Workout.

Deliverables:

Guide to preparing a project plan

Preparing a project plan enables you to control the project by:

  • defining the scope – specify the activities which need to be performed to complete the project scope and the target dates for their completion;
  • assigning accountability – identify an owner for each activity who will be accountable for its completion;
  • monitoring progress – provide the baseline against which progress will be measured.

The content and format of the schedule plan are described in the following sections. While these deal with schedule plans, the approach is also valid for the related resource and cost plans which should always use the same work breakdown structure.

Projects which are designed solely by one person usually lack the quality and level of involvement necessary for achieving extraordinary results.  This illutrates the vital team-building benefits of working together at the start of the project. However, the benefits are far more practical and tangible than that. If a team develops an approach to the project and plans it together, there will be debate and argument based on the differing perspectives of each team member. As a result of such discussions, each member will come to understand the needs and viewpoints of the others. Building a good plan is hard work, however, once done, all the reasons for it being as it is are embedded in the minds of those who created it. Each individual is less likely to make independent decisions on his/her work scope which will have adverse effects on the work of others. Similarly, when things go wrong (as they probably will), the team will know more instinctively the correct way to handle it. Team members will be more likely to concur on the method of resolution: they will have already cleared away all the interfunctional blockages in their minds when they created the original plan.

For more information see Chapter 19 of the Project Workout.

Deliverables:

Guide to defining you organisation

Once you have your project defined and planned out you should make sure that other organizational aspects of the project are addressed, including defining:

  • project administration needs (filing);
  • project progress reporting needs;
  • who can authorize changes to the project;
  • what formal review points are required.

For more information see Chapter 19 of the Project Workout.

Guide to engaging your stakeholders

Every project will create some change in the organization; otherwise there is no point in undertaking it! However, some changes are “easier” to effect than others as they align with the status quo and do not cross any politically sensitive boundaries. In essence, most of the people carry on as they always have done. Other changes, however, are fundamental and will result in shifts in power bases internal to the organization or even external, such as unions, suppliers, or customers.

Stakeholders are those affected by the project. All those involved in the project are, therefore, stakeholders. However, there are also those who take no direct part in the project as team members, but whose activities will in some way be changed as a result. These could be users of new systems, people in new departments resulting from reorganizations (or those made redundant), those taking roles in new processes as managers, supervisors, and and workers. Often the project is of little importance to them but they are of great consequence to the project if their consent is critical to success. It is essential to identify them because it is critical to enroll them at an early stage in the project to ensure their power does not cause the project to fail later. Never under-estimate stakeholders’ ability to ruin your best laid plans!

Never underestimate stakeholders’ ability to ruin your best laid plans!

It is both the project manager’s and project sponsor’s role to ensure that all stakeholders are adequately briefed on the project. Too much communication will drown them – they won’t read it. Not enough will mean your project will be lower down their priority list than you want it to be.

Engaging stakeholders and keeping them enrolled is a taxing but essential task. It is accomplished both by a formal communication plan and by “enrolling behavior” on behalf of all the project team on both a planned and opportunistic basis.

For more information see Chapter 19 of the Project Workout.

Guides for running a project

Guide to managing benefits

Realizing benefits is the sole reason for undertaking a project. If there are no benefits, there should be no project. It is for this reason that the role of project sponsor is vital. He or she is the person in the organization who requires the benefits to fill a particular need, in pursuit of a stated business objective.

To be “legitimate,” a project must satisfy at least one of the following conditions:

  1. maintain or increase profitable revenue to the business, now or in the future;
  2. maintain or reduce the operating costs of the business, now or in the future;
  3. maintain or reduce the amount of money tied up within the business, now or in the future;
  4. support or provide a solution to a necessary or externally imposed constraint (e.g. a legal or regulatory requirement).

In short, benefits are about making more money, about using existing resources and assets more efficiently and about staying in business. Drivers are frequently defined by words such as “growth,” “efficiency,” “protection,” “demand” which reflect an organization’s focus at any point in time.

The first three conditions relate to the net cash flow into the organization. Money is the organization’s key measure of commercial performance in the private sector and value for money in the public sector. It includes measurement of revenue, investments and the costs of running the organization.

The fourth condition is often referred to as a “must do” project. It is nevertheless essential that such projects are fully costed in order to determine the least cost, highest value approach to fulfilling the need. This cost can then be placed in the context of the organization as a whole in order to determine whether the organization, or the impacted part of the organization, can afford the change and remain viable.

For more information see Chapter 20 of the Project Workout.

Guide to managing the schedule

You will find the management of the project schedule is one of the most important and fundamental of project management techniques; so much so that many people (wrongly) think that schedule management is project management. At a simple level, the schedule tells you how long the project, or any part of it, will take. In addition to giving dates, a well produced project schedule also tells you:

  • who is accountable for every aspect of the project;
  • the approach being undertaken;
  • the major deliverables from the project;
  • the timing of key review points.

The schedule is also the basis on which cost and resource plans are constructed. However, unlike costs and resources, which are seen by only a few people observing a project, key dates are very visible. A well publicized delivery date for a project is, when missed, very hard to hide. While “time” may not be the most important aspect for you on some of your projects, an observer may develop their own perception of “success” or “failure” purely from the performance of your project against the publicized target dates.

The ability to build and manage the schedule plan is one of the essential skills that all project managers should have. Planning is far too important for you to delegate to junior team members, especially in the early stages of the project when the overall strategy and approach are being developed. The plan sets the course for the remainder of the project. Once agreed and set (at the Development Gate) it is very difficult to change or improve on. All the decisions which have the most leverage on time, costs and benefits will have already been made.

Planning is far too important for you to delegate to junior team members, especially in the early stages of the project when the overall strategy and approach are being developed. Done effectively, the project plan will benefit you and the team by providing:

  • a baseline against which to measure progress (without a plan, words such as “early” or “late” have no meaning);
  • a common understanding of the approach you are taking to achieve your objectives;
  • a breakdown of the project workload into manageable pieces (work packages) based on the deliverables/outputs wherever possible;
  • a clear way of showing interdependencies between activities and work packages within the project and to/from other external projects;
  • a listing of accountabilities for different activities and work packages;
  • a tool for evaluating when corrective action is needed.

Further, the actual activity of creating a project plan by using the full team serves to forge a team spirit and a high level of common commitment.

For more information see Chapter 21 of the Project Workout.

Guide to managing the finances

After managing time, management of the finances is the next most important and fundamental aspect of project management. Without a good schedule plan it is impossible to have a reliable financial plan. However, while the schedule is the aspect of a project most visible to outsiders, cost is often the most visible to insiders, such as the management team – sometimes it is the only aspect they see (or want to see!). At a simple level, a financial plan will tell you:

  • what each stage and work package in the project costs;
  • who is accountable for those costs;
  • the financial benefits deriving from the project;
  • who is accountable for the realization of those benefits;
  • financial commitments made;
  • cash flow;
  • financial authorization given.

In addition, some organizations also derive the net effect of the project on their balance sheet and profit and loss account.

Just as the schedule plan is used as the baseline for measuring progress in terms of “time,” the financial plan is the basis for measuring costs and financial benefits. Many of the other principles I have already explained on schedule management are also applicable to the management of finances. Schedule and cost plans should share the same work breakdown structure (WBS) (see p. 137). By doing this you ensure that:

  • accountability for both the schedule and cost resides with the same person;
  • there is no overlap, hence double counting of costs;
  • there is no “gap,” i.e. missing costs.

The costs are influenced by the following, which you must take into account when drawing up your plan:

  • the scope of the project;
  • the approach you take to the project;
  • the timescale to complete the project;
  • the risks associated with the project.

For more information see Chapter 22 of the Project Workout.

Guide to managing risks and opportunities

Risk is any potential uncertainty, threat, or occurrence which may prevent you from achieving your defined business objectives and benefits. It may affect timescale, cost, quality or benefits. All projects are exposed to risk in some form but the extent of this will vary considerably.

Opportunity is the possibility that your project may go better than you planned.

A risk will become an issue if the event occurs. Issues can be resolved either within the scope of the project as currently defined or via a change to the project. An opportunity is similar to a risk but has a potentially beneficial impact rather than a negative impact. Like risk, an opportunity will become an issue if the event occurs. Figure 23.2 also shows that, once the project is well under way, the risk, or “down side” is usually bigger than any “up side” opportunities.

The purpose of risk and opportunity management is to ensure that:

  • risks and opportunities on projects are identified and evaluated in a consistent way;
  • risks to the project’s success are recognized and addressed and significant opportunities are exploited without undue delay.

You cannot use risk management to eliminate risk altogether, but by careful planning, you may be able to avoid it in some instances or minimize the disruption in others. But what if identified risks do not materialize? What if a new approach (opportunity!) comes about which will further your business objectives better than planned? You have two options:

  • You can keep to the original plan, as something quite unexpected may still go wrong and eat into the time and money you’ve saved.
  • You can build the new found opportunity into the project and “mine it” for all it’s worth.

Traditionally, the former approach is the more prudent but that does not mean it makes the most business sense in all cases.

For more information see Chapter 23 of the Project Workout.

Deliverables:

Guide to managing issues

Issues management is the process for recording and handling any event or problem which either threatens the success of a project or represents an opportunity to be exploited. An issue occurs either as a result of an identified risk or opportunity event occurring or as a result of some unexpected event. An issue can either be dealt with within the project, as defined, or will require a change in order to keep the project viable. Examples of issues are:

Problem issues:

  • the late delivery of a critical deliverable;
  • a reported lack of confidence by users;
  • a lack of resources to carry out the work;
  • the late approval of a critical document or deliverable;
  • a reported deviation of a deliverable from its specification;
  • a request for additional functionality;
  • a recognized omission from the project scope.

Opportunity issues:

  • a contract negotiation is concluded early;
  • a breakthrough on a new technology cuts months off the development time;
  • a new, cheaper source of raw materials is located;
  • the enrollment of key stakeholders happens sooner than planned;
  • a contract tender comes in significantly less than the pre-tender estimate.

An issue is something that has happened and either threatens or enhances the success of the project. Compare this to a risk or opportunity which are things that might happen.

When talking to people be careful, as “issue” can also mean a “topic” or an “important point”: unless you are both tuned to the same definition you may find your conversations confusing!

For more information see Chapter 24 of the Project Workout.

Deliverables:

Guide to controlling change

Changes are an inevitable fact of project life. Seldom does a project go exactly to plan. Unless you manage these changes effectively you will soon lose sight of the objectives and scope and thereafter lose total control of the project.

Controlling change does not mean preventing change, but rather allowing only beneficial changes to be adopted and included in the project.

Change control is related to risk, opportunity and issue management; a risk or opportunity will become an issue if the event occurs. Issues can be dealt with either within the scope of the project as currently defined or via a change to the project. If this “issue” is to be resolved by a change to the defined project, the impact of this change should be assessed, particularly with respect to the expected benefits. (see Figure 25.1).

Change may result from a number of sources:

  • changes in business needs/requirements driven by the project sponsor or other stakeholders;
  • changes in the business environment (e.g. economics, social factors, competitor action);
  • problems or opportunities which occur during the course of the project;
  • modifications or enhancements identified by the project team (beware of these!);
  • faults detected by the project team or users (these must be addressed).

Change, in the context of a project, is any modification to the benefit, scope, time, or cost targets that have previously been approved. This means that there can only be a “change” if there is an approved standard or “baseline.” The baseline is provided by the project definition (included in the initial and full business case) which defines the:

  • benefits to be realized by the project;
  • scope of work and detail for each deliverable;
  • project timescale and intermediate milestone dates;
  • project cost.

For more information see Chapter 25 of the Project Workout.

Deliverables:

Guide to undertaking reviews

Your project is underway and may have been running for a long time. The team will be immersed in the day-to-day work of building and delivering the required outputs. This is when you are in danger of losing focus on the real business objectives which initiated the project in the first place. It is vital that you lift yourself above the day-to-day workload and review whether:

  • the project still serves your business objectives;
  • the conditions of satisfaction are clearly understood and are being pursued;
  • continuation of your project is still justified before further costs are committed to (e.g. signing a major contract);
  • your project is being effectively managed and the team is confident that the project will be completed.

Such reviews are an indispensable part of good project management, reassuring you, if you are the project sponsor, that the benefits you require will in fact be realized and, if you are the project manager, giving you an independent view on the effectiveness with which you are running the project. You should always welcome reviews as they are the opportunity to correct any shortcomings or improve those things which are going well to make them even better.

For more information see Chapter 26 of the Project Workout.

Guide to closing the project

The objective of project closure is to ensure that:

  • a project is closed down in a controlled and organized way;
  • all accountabilities relating to it have been discharged or handed over to the line or to another project.

Closure is the formal “end-point” of a project, either because it is completed or because it has been terminated. Termination may occur because the project is no longer viable or because the risks associated with it have become unacceptably high. The closure review should:

  • review the efficiency of the project in terms of meeting the original time, cost and scope;
  • confirm that the benefits have been built into the business forecast;
  • record and communicate any lessons which can be beneficial to future projects.

As far as the project sponsor is concerned, either the project has been completed and he/she can now expect to benefit from it, or the project has been terminated. In the latter case, this may be because the original business need no longer exists, but if it does, the project sponsor will need to take action to address the unresolved business need which initiated the project in the first place.

There are three key steps to closing a project:

  1. Prepare the closure report.
  2. Formally close the project.
  3. Close down and communicate.

For more information see Chapter 27 of the Project Workout.

Project Workouts

Workout 1.1 Self diagnosis

References

Workout 2.1 Review of the ten lessons

References

Workout 2.2 What happnes to project managers in your organisation whn the project is finished?

References

Workout 3.1 Tailor your own framework

References

Workout 4.1 Roles and accountabilities

References

Workout 5.1 Checklist for starting the initial investigations stage

References

Deliverables:

Workout 6.1 Checklist for starting the detailed investigation stage

References

Deliverables:

Workout 7.1 Checklist for starting the develop and test stage

References

Deliverables:

Workout 8.1 Checklist for starting the trial stage

References

Deliverables:

Workout 9.1 Checklist for starting the release stage

References

Deliverables:

Workout 10.1 Checklist at project closure

References

Workout 11.1 Checklist at post-implementation review

References

Workout 14.2 Chunks of change

References

Workout 14.3 The project environment

References

Workout 14.1 Starting to build your business programme

References

Workout 15.1 Decision making bodies

References

Workout 16.1 What's your white space

References

Workout 17.1 Reorganisation

References

Workout 17.2 Fighting your way through the office fog

References

Workout 17.3 Your own systems

References

Workout 19.1 Your first team meeting

.

References

Workout 19.2 Defining a project

References

Deliverables:

Workout 19.3 Project defintion checklist

References

Workout 19.4 Project organisation checklist

References

Workout 19.5 Stakeholder influence mapping

References

Workout 19.6 Stakeholder communication planning and tracking

References

Workout 20.1 Why are you doing this project now?

References

Workout 20.2 Linking objectives to deliverables

References

Workout 20.3 Transfiguration

References

Workout 21.1 Starting the plan off

References

Deliverables:

Workout 22.1 Project finances

References

Workout 23.1 Identifying risks - 1

References

Deliverables:

Workout 23.2 Identifying risks - 2

References

Deliverables:

Workout 23.3 Opportunity - 1

References

Deliverables:

Workout 23.4 Opportunity - 2

References

Deliverables:

Workout 24.1 Resoving issues

References

Deliverables:

Workout 25.1 Do you control changes on your project?

References

Deliverables:

Workout 26.1 Project Healthcheck

References

Deliverables:

Workout 27.1 Closure checklist

References

IPA Standards and Guides

Project Assurance Code of Practice

Function: Assurance

Owner: IPA

Assuring projects right

This project assurance code of practice provides guidelines for the assurance of major projects and appropriately scaled for projects of all sizes.

The Senior Sponsor will be committed to the principles of project management and assurance.

Assurance reviews will be part of a planned and integrated assurance regime to support the effective delivery.

Assurance reviews will be prioritised and resourced commensurate with risk potential, impact, complexity and strategic priority.

Assurance reviews will be carried out at appropriate points throughout the entire project lifecycle, with emphasis on policy formulation and project initiation.

Lessons learned from assurance reviews will be shared across the project delivery community at national and local levels.

An assurance review team must be independent of the project, its management and associated support activities.

Review teams will be drawn from an effectively managed reviewer pool of accredited peers, with the requisite skills, knowledge and experience commensurate with the project’s risk potential.

Review teams will have access to all stakeholders and documentation, with information obtained treated as confidential and reports non-attributable.

Assurance reviews will be strategically focused and forward looking and adopt a coaching style, with a ‘no surprises’ approach.

Assurance review assessments will be evidence based, objective and outcome focussed, delivering a report to the SRO on the final day of the review.

Review recommendations will indicate what needs to be addressed and be prioritised for urgency of implementation.

The SRO will be responsible for the effective implementation of recommendations arising from assurance activities.

Links:

Assurance and approvals for agile delivey of digital services

Owner: IPA

Function: Assurance

Assurance and approvals for agile delivery of digital services

Links:

Common Minimum Standards for procurement of the built environments in the public sector

Owner: IPA

Function: Common Minimum Standards for procurement of the built environments in the public sector

Links:

Crown Commercial Services

Links:

Strategic Supplier Management

Owner: Crown Commercial Services

Function: Commercial

Strategic Supplier Management (currently being revised)

Links:

Spending Controls Guidance

Owner: Crown Commercial Services

Function: Commercial

Spending Controls Guidance

References

Links:

HMG Information Assurance Standards

Owner: Office of Cyber Security and Information Assurance (OCSIA), Cabinet Office

Function: Cyber, Information Security and Information Assurance

HMG Information Assurance Standards

Links:

CESG Good Practice Guides

Owner: Office of Cyber Security and Information Assurance (OCSIA), Cabinet Office

Function: Cyber, Information Security and Information Assurance

CESG Good Practice Guides

References

Links:

HMG Security Policy Framework

Owner: Office of Cyber Security and Information Assurance (OCSIA), Cabinet Office

Function: Cyber, Information Security and Information Assurance

HMG Security Policy Framework

References

Links:

Government Digital Services

Links:

Digital by default standard

Owner: Government Digital Service (GDS), Cabinet Office

Function: Digital and Technology

Digital by Default Standard

References

Links:

Technology Code of Practice

Owner: Government Digital Service (GDS), Cabinet Office

Function: Digital and Technology

Technology code of practice

References

Links:

Service design manual

Owner: Government Digital Service (GDS), Cabinet Office

Function: Digital and Technology

References

Links:

Spending Controls Guidance

Owner: Government Digital Service (GDS), Cabinet Office

Function: Digital and Technology

Links:

HM Treasury

Links:

Managing Public Money

Owner: HM Treasury (HMT)

Function: Finance

References

Links:

The Green Book

Owner: HM Treasury (HMT)

Function: Finance

The Green Book: Appraisal and Evaluation in Central Government

References

Links:

Government financial reporting manual

Owner: HM Treasury (HMT)

Function: Finance

References

Links:

Consolidated Budgetting Guidance

Owner: HM Treasury (HMT)

Function: Finance

References

Links:

Supply estimates guidance manual

Owner: HM Treasury (HMT)

Function: Finance

References

Links:

Sustainability Reporting Guidance

Owner: HM Treasury (HMT)

Function: Finance

References

Links:

Cabinet Office

Links:

Civil service management code

Owner: Cabinet Office

Function: HR

References

Links:

Recruitment Principles

Owner: Cabinet Office

Function: HR

Recruitment Principles (Spending Controls Guidance)

Links:

IPA capability framework

Owner: Cabinet Office

Function: HR

Links:

Civil Service Pension Scheme Rules

Owner: Cabinet Office

Function: HR

Civil Service Pension Scheme Rules

References

Links:

IPA SRO/PD guidance

Owner: Cabinet Office

Function: HR

References

Links:

External Sources

AXELOS

PRINCE2

PRINCE2 (Project In Controlled Environment 2) – is a structured project management method

MSP

MSP (Managing Successful Programmes) - represents proven programme management good practice in the successful delivery of transformational change through the application of programme management.

PRINCE2 Agile

PRINCE2 Agile - incorporates agile concepts with the Prince 2 project management methodology.

P3O

P30 (Portfolio, Programme and Project Offices) - provides a decision enabling/delivery support structure for all change within an organisation.

P3M3

P3M3 (Portfolio, Project and Programme Management) - is a maturity model for project management and provides a framework within which organisations can assess their current performance and plan for improvement when managing and delivering change.

MoR

MoR  (Management of Risk) – is a route map for risk management.

ITIL

ITIL (IT Infrastructure Library) - provides guidance to organisations and individuals on how to use IT as a tool to facilitate business change, transformation and growth.

MoV

MoV (Management of Value) - provides essential guidance on the most efficient use of resources to maximise the benefits from portfolios, programmes and projects.

MoP

MoP (Management of Portfolios) guidance provides a set of principles, techniques and practices to introduce or re-energise portfolio management.

BS6079 Part 1: Project management. Principles and guidelines for the management of projects

ISO 21500 – guidance on project management.

Managing Benefits

Managing Benefits - guidance on the tools, techniques and best practice processes for benefits management.

Government Internal Audit Agency

Function: Internal audit

Public sector internal audit agency

The Law Society

Lexcel

Function: Legal

Excellence in legal practice management and client care, industry recognised standards.

Government Property Unit

National Property Controls

The way we work guidelines for smarter working

Robert Buttrick on the project lifecycle - video

This is a video in which Robert Buttrick expains the Project Franework, using the BusinessOptix model.

References

Salesforce APP for the Project Workout

A short video expalining the salesforce App which has been developed to support the Project Workout.

References

Project Workout links

Project Workout blog

The Project Workout Blog, including lots of mini artickes and discussions which you can comment on and add your own views.

References

Project Workout - Contact us

It is my vision to see organisations (both public and private) thrive through directing and managing their futures using effective, business led project and programme management techniques. I foresee a time when:

  • all significant change is directed and managed cross-functionally, harnessing people and resources from across and outside the organisation;
  • people find it second nature to form and perform in multidisciplinary project teams, focussed on achieving business benefits;
  • project skills and knowledge is a core capability of ALL managers and top executives.

I believe the best way to achieve this goal is to work with people, helping them to help themselves, ensuring they understand the practices and can carry them forward themselves.

You can contact Robert at Project Workout by clicking on the link, below.

References

Project Workout Method

The Project Workout's method, its activities, roles, RACI, deliverables and guidance.

References

Project Workout - register

Project Workout's processes

This shows you how the activities needed to direct and manage a project fit together, with templates, guidance, RACI and process flow.

References

Project Workout's project framework

The project lifecycle, a stage at a time, with activities, RACI, templates and process flow.

References

Project Workout web site

The link to the project Workout web site.

References

Articles and white papers

PRINCE2 and national and international standards

A white paper on how PRINCE2 measures up to BS6079 Part 1 and ISO 21500.

References

IPA links

Infrastructure and Projects Authority

IPA provides expertise in infrastructure and the financing, delivery and assurance of major projects, to support more effective management and delivery across government.

IPA is part of the Cabinet Office and HM Treasury.

References

Crown Commercial Service

The Crown Commercial Service (CCS) brings together policy, advice and direct buying; providing commercial services to the public sector and saving money for the taxpayer.

CCS is an executive agency, sponsored by the Cabinet Office.

References

Office of Cyber Security and Information Assurance

The Office of Cyber Security & Information Assurance (OCSIA) supports Cabinet Office ministers and the National Security Council in determining priorities in relation to securing cyberspace. The unit provides strategic direction and coordinates the cyber security programme for the government, enhancing cyber security and information assurance in the UK.

References

Government Digital Service

GDS helps departments work together to transform government and meet user needs.

GDS is part of the Cabinet Office and the Efficiency and Reform Group.

References

HM Treasury

HM Treasury is the government’s economic and finance ministry, maintaining control over public spending, setting the direction of the UK’s economic policy and working to achieve strong and sustainable economic growth.

HMT is a ministerial department, supported by 12 agencies and public bodies.

References

Cabinet Office

The Cabinet Office supports the Prime Minister and ensures the effective running of government. We are also the corporate headquarters for government, in partnership with HM Treasury, and we take the lead in certain critical policy areas.

Cabinet Office is a ministerial department, supported by 19 agencies and public bodies.

Praxis Method Links

Praxis framework web site

References

Resources

References

Encyclodedia

References

Project Workout deliverables and templates

The Project Workout includes a number of templates and descriptions of deliverables. You can find these in the Project Workout Method.

References

Links:

Benefits plan

Plan showing overall benefits for the programme or project.

Business case

The Business Case contains the business rationale for the project. It is the document which outlines WHY you need the project, WHAT options you intend to work on, HOW you will do it, and WHO is needed to make it happen. It also answers the question HOW MUCH? and hence is used to authorise the funding for at least the next stage of the project. The Initial Business Case does not comprise a full analysis, but only sufficient to enable you to decide if it is worthwhile continuing the project. The Full Business Case provides the definitive appraisal for the project.

WHAT options you intend to work on, HOW you will do it, and WHO is needed to make it happen. It also answers the question HOW MUCH? and hence is used to authorise the funding for at least the next stage of the project. The Initial Business Case does not comprise a full analysis, but only sufficient to enable you to decide if it is worthwhile continuing the project. The Full Business Case provides the definitive appraisal for the project.

References

Business plan

Overall plan for the business programme including objectives, benefits, risks and constraints.

Business strategy

Strategy is the bridge between policy or high-order vision on the one hand and tactics or concrete actions on the other. Strategy provides general guidance for developing specific plans in pursuit of particular ends.  This means that the necessary precondition for formulating strategy is a clear and widespread understanding of the ends to be obtained (vision). Without a vision, action is purely tactical and can quickly degenerate into nothing more than a flailing about.

Change log

The purpose of the change log is to provide a record of all changes requests which have been submitted and the resulting actions and decisions.

References

Systems:

Change request form

The purpose of the change request form is to summarise a change request, its impact and decision or direction resulting.

References

Document register

Register of all version controlled documentation for the project or work package.

Feasibility report

The Feasibility Report builds on the Initial Business Case. It includes the recommendation for which option should be adopted as the solution (including processes), and compares it against rejected solutions in financial and non-financial terms.

References

Finance plan

Plan showing overall costs for the programme, project or work package. If the project is revenue earning, then income should also be tracked.

Gate request

A formal request to obtain authorisation to start a new stage of the project or, at the end, request formal closure.

Gate decision record

The gate decision records includes the outcome of a gate review meeting, the reasons for the outcome, any directions, together with a checklist of criteria.

Health check

The project health check is a tool to assess the current "health" of a project. It looks at the full project environment and, using a set of key questions, results in an assessment of the overall risk associated with a project. As such it fulfils two roles:

  1. as a check-list
  2. as a tool to indicate whre the project sponsor and team's efforts should be directed.

References

Issues log

The purpose of the issues log is to provide a record of  issues which have been raised and which threaten the project's business objectives.

References

Systems:

Output defintion

The Output Definition is the fundamental document set describing the output of the project in terms of process, organisation, systems, technology and culture. It is the document which integrates all the individual system, process and platform requirements. It also specifies how they will work together. The document set will continue to develop as the project proceeds and will be handed over to the manager(s) of any operational parts before the project is completed.

References

Plan(s)

A plan comprises the integration of the schedule, costs, resource and scope for a project or work package.

Post-implementation review report

The Post-Implementation Review (PIR) report assesses the success of the project against predefined criteria given in the business case and confirmed in the terms of reference for the PIR. It assesses how effective the project was in meeting its objectives and includes recommendations for improvements.

References

Progress report(s)

The purpose of the progress report is to provide the  a summary of the progress to date  and the outlook for the future. It is also used to advise of or escalate any potential problems or areas where help is required.

Project documentation

Project documentation is the collective term for the management, defntion and contral documentation for the project, such as business case, output definiton, project plan, risk log, issues log, change log.

Project log

The project log contains the key control logs for managing a project, including those for risks, issues, changes and decisions.

References

Project closure report

The Project Closure Report contains the notes of solution handover and project closure, including ‘lessons learned’ from the project in terms of how the processes, organisation, systems and team worked (i.e. the efficiency of the project). A terms of reference for the Post-Implementation Review is also included.

References

Project plan

The Project Plan is a key appendix or supporting document to the business case and defines the schedule, cost, and resource requirements for the project. This is defined in summary to completion of the project and in detail for the Detailed Investigation Stage.

Project register

The Project Register is a definitive list of projects, together with the names of the sponsor and manager. Additional information, such as project status and key dates may also be added.

Project review report

The purpose of the Project Review Report is to record a review of the project together with any recommendations for corrective or preventative actions.

References

Proposal

The Proposal is a very brief document (one to five pages) which outlines the need the project will meet, what it is intended to produce (if known), its benefits, and how it fits with current strategy. If known, the impact on the organisation (market, technology and operational), broad estimates of benefits and cost, and required time to completion are also included.

References

Ready for service review report

The Ready For Service (RFS) review report is a short report which confirms that all deliverables and prerequisite activities required before starting the Release Stage have been completed

References

Ready for trial review report

The Ready for Trial Review Report is a short report which confirms that all deliverables, resources, and prerequisites across all functions required for starting the trial are in place

References

Resource plan

Plan showing overall resource needs for the programme, project or work package.

References

Review report

A review report comprises a summary of the findings and recommendations redulting from a review. It provvides information to help the sponsor assure that the project will meet its business objectives or, decide to make changes such that those objectives can be achieved.

Risk log

The purpose of the risk register is to provide a record of risks to the project's objectives, their analysis, treatment and status.

References

Systems:

Schedule plan

Plan showing overall time-scales for the programme, project or work package.

References

Test plan

The Test Plan documents the tests required to verify performance of any outputs from the project both in isolation and working as a complete system

References

Test results

The Test Results verify that any testing has been completed in accordance with the test plans and acceptance criteria, prior to doing the ready for trial review. Any outstanding issues are noted

References

Trial plan

The Trial Plan documents the way in which the output will be piloted and the criteria for determining whether it was successful

References

Trial results

The Trial Results is a summary document which confirms that the trials have been completed in accordance with the plan and acceptance criteria, and the developed solution is now ready to move to the Release Stage. Any outstanding issues are also noted

References

Vision

Vision is a clear and widespread understanding of the ends to be achieved.

ISO

Accurate and timely information

Activity duration estimates

Activity list

Activity sequence

Actual costs

Approved changes

Budget

Business case

Change register

Change requests

Completed procurements

Communication plan

Contract

Contract documentation

Contracts or purchase orders

Corrective actions

Cost estimates

Deliverables

Distributed information

Existing contracts

Forecasted costs

Historical data

Industry standards

In-house capability and capacity

Inspection reports

Issues log

Lessons learned from previous projects

Lessons learned

Lessons learned document

Make-or-buy decision list

Preferred suppliers list

Previous phase documents

Previous phase results

Prioritized risks

Procurement plan

Progress data

Progress reports

Project charter

Project completion reports

Project or phase closure report

Project organization chart

Project plans

Project plan

Project management plan

Project statement of work

Quality control measures

Quality control requirements

Quality plan

Quality policy

Quality requirements

Released resources

Request for information, proposal, bid, offer or quotation

Requirements

Resource availability

Resource plan

Resource requirements

Risk register

Risk responses

Role descriptions

Schedule

Schedule constraints

Scope statement

Selected suppliers list

Staff appraisals

Staff assignments

Staff contracts

Staff performance

Stakeholder register

Statement of work

Subsidiary plans

Supplier's tenders

Team appraisals

Team performance

Unexpected requests

Verified deliverables

Work breakdown structure

Work breakdown structure dictionary

Network Rail deliverables

0.0 Series

Client remit

This is the project brief from Client to Sponsor outlining the project objective/requirements of the Client.

If the Client is external, it may be the case for the Sponsor to complete the Project Proposal Form to establish the project brief.

The brief should include an outline of the consents required. An assessment of Client Needs/Requirements is to be undertaken against the "Quad of Aims". Minutes of meetings are to be included as an appendix within the remit.

References

Needs analysis

Identification of objectives and success criteria for the project including desired outputs, available funding sources and a high level risk assessment by the sponsor which confirms that these are acceptable to the business. Where Schemes are identified within the RUS, this document can be considered to be the Needs Analysis.

Business Plan

For renewal project ONLY.

Please refer to the relevant processes and procedures with your own Asset Management Function for details on creating and updating the Business Plan.

1.0 series - Project Management

Management level of control

The Management Level of Control [NR/L3/INI/PG115/PS/001] standard provides a decision making approach about what effort is required for planning and reporting each specific project, taking into account team competence, experience and difficulty of the project. The LOC category should be reviewed at every GRIP stage up to GRIP 6.

References

Project LoC assessment tool

Used to assess the LOC Category of a project.

Sponsor's instructions

Outlines the project scope and stage deliverables, confirms available budget, and provides an overview of key information regarding the project e.g. the agreed timescales, the project team, key stakeholders, etc. The Document is subject to upversion at each GRIP Stage.

Project management plan

This Plan defines how the PDM/PM will discharge the requirements defined within the Sponsor Instruction.

Stakeholder management plan

Comprises a plan defining the management responsibilities for the relationship between Sponsor, Client and stakeholders including requirements for G&CA involvement with Third Parties

References

Stage kick off meeting notes

Provide a clear and concise set of notes and associated actions which can be used to help control a successful GRIP stage outcome. The meeting is arranged by the Sponsor with key team players being present.

Stage gate reviews

Stage Gate Reviews are key checkpoints within a project to establish that a project has delivered Products that were specified to be delivered, and if the project can proceed to the next Stage.

Stage gate review checklist

The Stage Gate Checklist shall be used to record whether products to be created or updated within a stage have been completed. it shall be signed and dated on completion of a Stage Gate review by both the Project Manager and Sponsor to indicate that the Project is fit to proceed to the next stage.

Scope and evaluation study

Purpose of this product is to confirm the Project Selection Criteria (PSC) and Critical Success Factors (CSF) against which options shall be evaluated. This is therefore one of the key products required to provide input into the GRIP 3 Option Selection.

Feasibility report

This product helps to establish the viability of the project business case through the analysis of high level options which must clearly align with the agreed Sponsor Instruction and Requirements specification.

Options selection report

The Product must provide sufficient and relevant detail to inform the Sponsor that an optimum solution to the opportunity/issue outlined within the Sponsor's Instruction and Requirement Specification has been achieved. It must demonstrate that a number of options have been explored and some have been dismissed through critical evaluation during the Stage 3 process.

The report must conclude with the justification for the preferred option supported by the relevant and sufficient backup material.

Asset management plan

Every project shall produce an Asset Management Plan using a selection of the forms listed within the Asset Management Plan Agreement [NR/L3/MTC/089/AMP003] The Project Manager shall determine and agree with the Maintenance Manager which forms are required for their project. The AMP confirms the type, number and location of new assets to be created by the Project and how they are to be managed and maintained through the Asset Management and Maintenance process.

Practical completion certificate

This product shall be issued at the point at which the scope of work defined under the contract has been completed to the extent that it is deemed fit for its intended purpose

Project completion report

This product shall detail all available information about the close out of the project.

Benefits review

The purpose of the Benefits Review is to check how many of the benefits have been delivered by the project. Every project has benefits, generally linked to the outputs, for which the Client is paying to be delivered.

Now that the change has been implemented, it is important to check whether the proposed benefits have been realised.

3.0 series - Risk and value management

Risk register

This product is used to record all risks throughout the duration of a project.

Output definition workshop report

This is a key undertaking in Stage 1 comprising a facilitated VM 1 Workshop to determine the project purpose and requirements (i.e. agreement of the Pre GRIP Needs Analysis) through the use of the “Quad of Aims” (or similar). Client and Key Stakeholders must attend. The Output should also include a high level Statement of Requirements as a precursor to the production of Sponsors Instruction and Project Requirements Specification in GRIP 2.

4.0 series - Consents and approvals

Land and consents strategy

The purpose of the Land and Consents Strategy is to identify the broad scope of land and consent requirements for a project and set out how these will be obtained/ satisfied and supported through the project.The Strategy is first required to be prepared in GRIP 1. From this point, the Strategy will be a live document that is reviewed as the project progresses.

5.0 series - Environmental management

Environmental risk assessment

The purpose of this product is to provide a mechanism for capturing all environmental risks and to establish adequate control measures, including, where appropriate, the production of emergency plans.

6.0 series - Engineering

Client requirements document

Produced by the Client, Group Strategy: Accountable for the development and management of the high level requirements which must be defined and captured in this document. Click here for guidance

Route requirements document

Produced by the Client within the Route: Accountable for the development and management of the route requirements which must be defined and captured in this document. Click here for guidance.

Praxis Method Documentation

Documentation

Documents fall into three categories: governance, scope and delivery.

Governance documents set out policies, standards and guidelines for the management of the work. Some of these may be specialist documents provided by the host organisation, a client or a regulatory body. Praxis only deals with the management plans that reflect how elements of P3 management will be managed.

Scope documents describe the objectives in terms of outputs, outcomes and benefits.

Delivery documents are the largest and most diverse group. They describe what needs to be done, when it will be done and by whom. They also support the management processes and procedures. As well as being listed in this section, documents are cross-referenced in the resource tables in the library. They are aligned with the topics from the knowledge section and the processes from the method section. For example the risk management plan appears in the resource page for risk management and also in the resource page for the definition process where it is first created.

Management plans

For a portfolio, governance documents will be created in the initiation process. In projects and programmes they are prepared in the definition process.

The document descriptions in this section are generic and will need to be tailored to suit the context. For example, where references are made to programme and portfolio level information these may not be appropriate for a project. High level scope and delivery documents are produced in the identification process, i.e. the first phase of the project or programme life cycle.

Since guidelines for the format and usage of these documents are set out in the governance documents it may seem odd that the governance documents are apparently not prepared until after these initial content and management documents.

In a more mature organisation governance documents will exist in a standard form ready to be adapted to different contexts. The standard governance documents will be used by competent members of the identification team to guide their documentation during the identification process. During definition, the standard governance documents will be tailored to the context of each project and programme, thus providing guidance for the detailed management and content documents thereafter.

These documents set out the way a function will be managed. The two main sections cover the policy and procedure of the function with the detail being adapted to the context of the work. This is distinct from a delivery plan, which explains the detail of how a specific piece of work will be delivered.

Policy includes sections on roles and responsibilities, information management, assurance, budget and interfaces to other functions.

Procedure begins with defining the steps to be used in performing the function, followed by detailed recommendations on the tools and techniques to be used in each step.

Management plans are created according to the needs of the work. If appropriate functions may be merged into one plan or a function may be sub-divided.

There is a danger that the following list of management plans appears highly bureaucratic and time consuming to prepare. The principle is simply that there are many functions that need to be managed and it is important to think about how that will be done. The range and detail of management plans should be consistent with the complexity of the work.

Stakeholder management plan

The stakeholder management plan sets out the preferred procedures, tools and techniques to be used in managing stakeholders. - See more at:

Organisation management plan

The need for an organisation management plan increases as the complexity of the work increases. On small projects an organisation will be in place before any management planning tak

At any point in time in a major portfolio there will be new project or programme organisations being set up, existing ones being adjusted or management teams being demobilised. In this case policies and procedures promote consistency and efficiency in the way organisations are managed.

Control management plan

Control is one of the central functions of P3 management. It is concerned with performing work in accordance with delivery documents and updating them based on actual performance.

Information management plan

There is an information management element to all other management plans that deals with the format and distribution of specific documentation. This management plan should not duplicate those policies. Rather, it is about general approaches to the creation, storage and dissemination of information.

Assurance management plan

Scope management plan

Scope is the defining characteristic when choosing to manage work as a project or a programme. The more complex the scope, the more extensive the range of management plans needed to describe how it will be managed.

An all-encompassing scope management plan, as described here, will work for less complex scope. As the complexity increases some parts of scope may need their own management plan, such as a benefits management plan for example. Ultimately, the scope management plan may be replaced by management plans for each aspect of managing scope.

Broadly speaking a scope management plan will exist for projects, whereas a programme will have separate management plans for the different components of scope management. Naturally there will be points in-between where there is an umbrella scope management plan supported by more detailed management plans as required.

Benefits management plan

A separate benefits management plan (as opposed to a benefits section in the scope management plan) will often be required where there are multiple benefits, significant change and the relationships between outputs and benefits are more complex, i.e. a benefits management plan is usually appropriate where the work is managed as a programme rather than a project.

Schedule mangement plan

Scheduling is often taken for granted as a routine well established procedure that would not justify a management plan of its own. Where simple projects are regularly performed this may well be the case although scheduling approaches should still be documented at an organisational or portfolio level and assured against this standard.

As more complex projects and programmes are undertaken, more thought should be given to the range of techniques available for both time scheduling and resource scheduling. This is particularly important where different parts of the work may need to use different techniques but still facilitate consolidation to produce high level schedules.

Finance management plan

Not all aspects of this plan will be relevant in some contexts. In other contexts it may be necessary to expand this into multiple management plans.

Projects that are part of a programme may not need to perform investment appraisal or establish funding. Major infrastructure programmes may need to develop a management plan for funding that is separate to the management plan for financial control.

Risk management plan

Change management plan

The effective management of change is vital in order to generate benefits from outputs. Changes to business as usual will be included in the scope of most projects, programmes and portfolios. There will always be resistance to change and implementing a clearly documented and consistent approach contributes to dealing with this resistance.

Resource management plan

Scope documents

Scope documents describe the objectives of the work. In many cases it is possible to define standard documentation that is independent of the environment, e.g. a business case or benefit profile. In others, the content is entirely dependent upon the technical nature of the work and so Praxis simply describes what is to be achieved by the document but cannot define any detail, e.g. a specification.

Mandate

The term mandate applies to whatever information is used to trigger the initiation process. It could be a minute in a management meeting, the award of a contract to supply or simply an email from a senior manager.

Vision statement

A vision statement is a brief description of the end goal of a complex project or programme. The need for a succinct and memorable description is necessary where there are many stakeholders who need to gain an insight into the end result of a complex piece of work. The purpose of this document is similar to that of an artist’s impression of a major construction project. It doesn’t provide much detail but gives a good understanding of what the work is all about. Often seen as something peculiar to programmes, the vision statement can be equally applicable to a project, particularly larger or more complex projects where stakeholders need to be engaged early in the life cycle.

Specification

Specifications define outputs and are created by the solutions development procedure. The structure and content of a specification is entirely dependent on the context. In construction a specification may comprise, layouts, elevations, bills of quantities, structural details and so on. In IT, a specification could be functional or technical.

The specification is whatever is required by good practice in the relevant context. In many contexts, the specification for an output may be formed from a series of descriptions of individual products. Some of these products may be deliverables in their own right and some tracked as configuration items in a configuration management system.

Business case

The business case is the central document to a project or programme life cycle. The reason for defining a life cycle with phases, tranches and/or stages is to enable go/no go decisions to be made that prevent wasted investment. These decisions are primarily made based on the viability of the business case.

References

Product documents

The extent and detail of product documentation is very dependent upon the context of the work. Rather than prescribe separate documents, Praxis provides a list of fields from which suitable documents should be constructed according to the needs of the project or programme. This may result in a simple approach with one document per product or a more extensive approach with separate documents for product descriptions, configuration items and quality records. - See more at: http://www.praxisframework.org/method/product-documents#sthash.5lRicSTp.dpuf

References

Blueprint

A blueprint is a form of specification. It is applicable to programmes of business change where the ultimate objective is a changed organisation and working methods. The blueprint represents the sum of all outcomes resulting from the outputs of projects and the change activity performed by business-as-usual.

References

Benefits map

A benefits map is a form of influence diagram and is needed where there are complex relationships between multiple outputs, benefits and the strategic objectives that the benefits support. Within these relationships there may be dis-benefits and outcomes that form a bridge between outputs and benefits. The map will take the form of a chart that illustrates:

  • Outputs
  • Outcomes
  • Benefits and dis-benefits
  • Strategic objectives
  • Dependencies between outputs, outcomes and benefits/dis-benefits -

Benefit profile

A benefit profile is used to define both benefits and dis-benefits. It is typically developed during the definition process of a project or programme following requirements management. The profile includes sections that describe the benefit or dis-benefit and how it will be realised and measured. -

References

Brief

The project or programme brief is created by the identification process and is one of the documents submitted to the sponsor to seek approval to start the definition process. During the definition process each section of the brief will used as a basis for development of multiple specialist documents. The version of the brief used for authorisation will then be archived.

References

Delivery documents

While the management plans set out the governance principles for how the work will be managed and the scope documentation defines what should be achieved, the delivery documents are at the heart of actually doing the work.

Which delivery documents are to be used and what their format will be, is defined in the management plans. They are primarily used in the delivery, development and boundaries processes.

Delivery documents are the most dynamic of the three documentation groups and should be maintained in accordance with the principles of information management and configuration management.

Defintion plan

The definition plan is created in the identification process and, alongside the brief, is one of the documents submitted to the sponsor to seek approval for the definition process. This document is based on the general delivery plan format and adapted to suit the context of the work. Since this plan only exists in conjunction with a project or programme brief, its content can be simplified to avoid duplication.

See more at: http://www.praxisframework.org/method/definition-plan#sthash.c2D6Q0dN.dpuf

References

Communication plan

The communication plan is based on the general delivery plan format with the scope being stakeholder communications. While focusing on the timing of communications, the plan may also include their cost, how they will be controlled and how they link to other delivery plans.

References

Stakeholder register

The stakeholder register records information about individuals and groups who have an interest in the work being performed.

References

Risk register

The purpose of the risk register is to record information about identified risk events. The amount of information that needs to be recorded will depend upon the context of the work.

In its simplest form (in a small self-contained project) the register will be a list of risk events and the results of qualitative analysis. A much more sophisticated risk register will be designed to enable aggregations across multiple projects and programmes. It will also record, or cross-reference to, more specialised documentation showing quantitative analysis of general uncertainty (e.g. Monte Carlo analysis or sensitivity analysis).

References

Issue register

The issue register records all problems that need to be escalated from one level of management to another.

References

Delivery plan

Delivery plans come in various shapes and sizes. The first delivery plan to be prepared will be the project or programme definition plan. Subsequently, delivery plans can be prepared to cover a part of the life cycle (e.g. a stage or tranche plan), a delivery component (e.g. a benefits realisation plan or communication plan) or a specialist plan (e.g. an exception plan or contingency plan). It is useful for all types of delivery plan to follow a consistent format although this should be adapted as necessary and not followed slavishly.

See more at: http://www.praxisframework.org/method/delivery-plan#sthash.sw8Sffq4.dpuf

References

Lessons log

A lessons log for a particular project or programme will have two distinct sections. The first is created in the review previous lessons activity during the identification process where lessons learned from previous work that are applicable to the current work are logged. The second section records lessons that have arisen in the conduct of the current work and may be applicable in the future.

See more at: http://www.praxisframework.org/method/lessons-log#sthash.g8avrTYF.dpuf

References

Daily log

A daily log is a personal document that records informal information that is not stored in any of the other defined documentation. It is primarily a diary of events that its owner can use as an aide memoire of conversations and decisions. It can also be a note of ideas or comments that will need to be recorded elsewhere at some point in time. For example, an initial thought about a new risk or an idea for a lesson to be recorded.

References

Change log

The change log records all requests for change and their progress through the change control procedure.

References

Progress report

Progress needs to be communicated at regular intervals. This may be, for example, from an individual to their team manager; from a contractor to a project manager; from a project manager to a programme manager. A progress report may cover a small work package, change management activity in a business area or an entire programme in a portfolio. Regardless of the scale or context, the principles are the same. The report needs to explain what has been done compared to what was planned; what comes next; what problems need attention; what lessons have been learned. A progress report is a time driven control document used in the delivery process. The content of an effective progress report is dependent upon the judgement of a competent manager who understands the needs of the report’s recipient. Content should reflect the context of the work and target audience.

References

Event report

In addition to time-driven progress reports, progress may be reported at a particular event. This may be more applicable to certain stakeholders and will also be an input to the go/no go decision process at the end of a defined segment of work e.g. the end of a stage within a project; the end of a contractor’s work package; the end of a tranche within a programme or the end of a project within a portfolio. Regardless of the scale or context, the principles are the same. The report needs to explain what has been done compared to what was planned; what, if anything, comes next; what lessons have been learned. The content of an effective event report is dependent upon the judgement of a competent manager who understands the needs of the report’s recipient. Content should reflect the context of the work and target audience.

References

Follow-on actions report

The nature of a follow-on actions report will vary considerably according to its context. In simple terms it must list the actions that remain outstanding when the project or programme team is demobilised. Such actions could relate to unfinished deliverables, corrective action on existing deliverables or tidying up managerial loose ends such as final payments. As a minimum the report should contain:

  • Description of the outstanding action
  • Owner
  • Planned date for resolution
  • Actual date of resolution.

See more at: http://www.praxisframework.org/method/follow-on-actions-report#sthash.qfn2cP4w.dpuf

References

Business Optix

MS Project

MS Project is probably the idest used deask top planning too. These templates include additional features ensuring the best practices in the Project Workout can be appled.

References

Project health check - Excel

The project health check is a tool to assess the current "health" of a project. It looks at the full project environment and, using a set of key questions, results in an assessment of the overall risk associated with a project. As such it fulfils two roles:

  • as a check-list
  • as a tool to indicate whre the project sponsor and team's efforts should be directed.

References

Project log - Excel

The project log contains the key control logs for managing a project, including those for risks, issues, changes and decisions.

References

Americas

USA

New York

Boston

Chicago

Washington DV

San Francisco

Denver

Houston

Canada

Montreal

Vancouver

Mexico

Mexico City

South America

Rio de Janeiro

Buenos Aires

EMEA

UK

London

Birmingham

Liverpool

Glasgow

Germany

Berlin

Bonn

Munich

Frankfurt

Stuttgart

France

Paris

Bordeaux

Marseilles

Scandinavia

part 98

Southern Europe

Rome

Barcelona

Lisbon

Eastern Europe

Moscow

Prague

Warsaw

Middle East

Bahrain

Jerusalem

Africa

Johannesburg

Cairo

Ireland

Ballsbridge

Kilorglan

Cabinteely

APAC

India

Mumbai

Bangalore

China

Shanghai

Australia & NZ

Melbourne

Other

Kuala Lumpur

Singapore

Project log - Excel

The project log contains the key control logs for managing a project, including those for risks, issues, changes and decisions.

References

Robert Buttrick on the project lifecycle - video

This is a video in which Robert Buttrick expains the Project Franework, using the BusinessOptix model.

References

Salesforce APP for the Project Workout

A short video expalining the salesforce App which has been developed to support the Project Workout.

References

Project Workout blog

The Project Workout Blog, including lots of mini artickes and discussions which you can comment on and add your own views.

References

Project Workout - Contact us

It is my vision to see organisations (both public and private) thrive through directing and managing their futures using effective, business led project and programme management techniques. I foresee a time when:

  • all significant change is directed and managed cross-functionally, harnessing people and resources from across and outside the organisation;
  • people find it second nature to form and perform in multidisciplinary project teams, focussed on achieving business benefits;
  • project skills and knowledge is a core capability of ALL managers and top executives.

I believe the best way to achieve this goal is to work with people, helping them to help themselves, ensuring they understand the practices and can carry them forward themselves.

You can contact Robert at Project Workout by clicking on the link, below.

References

Project Workout Method

The Project Workout's method, its activities, roles, RACI, deliverables and guidance.

References

Project Workout web site

The link to the project Workout web site.

References

Infrastructure and Projects Authority

IPA provides expertise in infrastructure and the financing, delivery and assurance of major projects, to support more effective management and delivery across government.

IPA is part of the Cabinet Office and HM Treasury.

References

Crown Commercial Service

The Crown Commercial Service (CCS) brings together policy, advice and direct buying; providing commercial services to the public sector and saving money for the taxpayer.

CCS is an executive agency, sponsored by the Cabinet Office.

References

Office of Cyber Security and Information Assurance

The Office of Cyber Security & Information Assurance (OCSIA) supports Cabinet Office ministers and the National Security Council in determining priorities in relation to securing cyberspace. The unit provides strategic direction and coordinates the cyber security programme for the government, enhancing cyber security and information assurance in the UK.

References

Government Digital Service

GDS helps departments work together to transform government and meet user needs.

GDS is part of the Cabinet Office and the Efficiency and Reform Group.

References

HM Treasury

HM Treasury is the government’s economic and finance ministry, maintaining control over public spending, setting the direction of the UK’s economic policy and working to achieve strong and sustainable economic growth.

HMT is a ministerial department, supported by 12 agencies and public bodies.

References

Cabinet Office

The Cabinet Office supports the Prime Minister and ensures the effective running of government. We are also the corporate headquarters for government, in partnership with HM Treasury, and we take the lead in certain critical policy areas.

Cabinet Office is a ministerial department, supported by 19 agencies and public bodies.

Business case

The Business Case contains the business rationale for the project. It is the document which outlines WHY you need the project, WHAT options you intend to work on, HOW you will do it, and WHO is needed to make it happen. It also answers the question HOW MUCH? and hence is used to authorise the funding for at least the next stage of the project. The Initial Business Case does not comprise a full analysis, but only sufficient to enable you to decide if it is worthwhile continuing the project. The Full Business Case provides the definitive appraisal for the project.

WHAT options you intend to work on, HOW you will do it, and WHO is needed to make it happen. It also answers the question HOW MUCH? and hence is used to authorise the funding for at least the next stage of the project. The Initial Business Case does not comprise a full analysis, but only sufficient to enable you to decide if it is worthwhile continuing the project. The Full Business Case provides the definitive appraisal for the project.

References

Change log

The purpose of the change log is to provide a record of all changes requests which have been submitted and the resulting actions and decisions.

References

Systems:

Change request form

The purpose of the change request form is to summarise a change request, its impact and decision or direction resulting.

References

Health check

The project health check is a tool to assess the current "health" of a project. It looks at the full project environment and, using a set of key questions, results in an assessment of the overall risk associated with a project. As such it fulfils two roles:

  1. as a check-list
  2. as a tool to indicate whre the project sponsor and team's efforts should be directed.

References

Issues log

The purpose of the issues log is to provide a record of  issues which have been raised and which threaten the project's business objectives.

References

Systems:

Plan(s)

A plan comprises the integration of the schedule, costs, resource and scope for a project or work package.

Risk log

The purpose of the risk register is to provide a record of risks to the project's objectives, their analysis, treatment and status.

References

Systems:

Schedule plan

Plan showing overall time-scales for the programme, project or work package.

References

Version : 1.1

Status : APPROVED

Modified : 22-July-2015

Security :

Executive Summary:

Welcome to the Project Workout's "community" site.

Confidentiality

All information in this document is provided in confidence for the sole purpose of adjudication of the document and shall not be used for any other purpose and shall not be published or disclosed wholly or in part to any other party without prior permission in writing and shall be held in safe custody. These obligations shall not apply to information which is published or becomes known legimately from some other source.

Many of the product, service and company names referred to in this document are trademarks or registered trademarks.

They are all hereby acknowledged.

Document Control
TitleThe Project Workout Community SiteCode
AuthorRobert ButtrickTemplateDiagram HTML v5.4.xsl
OwnerRobert ButtrickFile Ref.The Project Workout Community Site.html
Approvals
ApproverRoleApproved?DateVersion
Review
NameRoleReviewed?DateVersion
Change History
VersionDateStatusAuthorDetails of Change
1.0 Draft A19-April-2014DRAFTRobert Buttrick

Initial draft

1.025-March-2015APPROVEDRobert Buttrick

Issued for use

1.113-July-2015APPROVEDRobert Buttrick

Minor update to layout.

Copyright © Business Optix Limited 2008-2015