Appendix B: A project process framework
‘Life is one long process of getting tired.’
SAMUEL BUTLER (1612–1680)
Teach me to cheat
How to document and organise your processes can pose a number of problems. In one company I visited, they proudly showed me their process documentation (all to ISO 9001:2008 standards), in lever arch files covering about 5 yards of shelves. I was not impressed and, in fact, they were hoping I wouldn’t be. This collection of files was their process before they reorganised it. After a pause, they pulled from the shelf a single, slim volume which was now the process documentation for the entire company. I asked how they managed this remarkable reduction. They told me they ‘cheated’ and would show me how to do the same. Their documentation was divided into three basic types:
The processes were very simple tabulations stating the activity, who is accountable, the deliverable and who it goes to. In addition, they have a further column which referred to any relevant templates or guides. Flow charts were only used, if necessary, for clarification. The documents were kept very brief and factual with no explanation, education or guidance.
The guides were the ‘education’ documents. They contained the principles, the methods, best practice and checklists.
The templates were the actual documents. They not only contained the titles of each document but also described what each section was for, rather like I have on p. 298. Each template was supplemented by a product description, describing its purpose, the content, the quality criteria and who should review and approve it.
The slim document I was shown was in fact the processes only. The remaining documents were the guides and templates. These were all very necessary documents but not needed all the time. Most users could work from the process alone; if they needed more, the cross-reference was supplied. Another advantage is that the system requires very little administration and also lends itself to intranet publication with the process at the core and the guides and templates hyperlinked in the appropriate places.
Process framework – some methodological context!
A suggested process framework and its component parts are included in Figure B.1, which shows the main processes and the information which passes between them. In the suggested approach, each process is based on the separate roles, introduced throughout the book (see Chapter 4 for project roles and Chapter 14 for business programme roles). For example, the executive team would undertake the ‘Direct and review business programmes’ process; the project manager would undertake ‘Control a project’. The separation of process by role, for management processes, ensures that the processes can be targeted at the appropriate users, without burying them in detail which has to be undertaken by others. Do note, however, that whilst writing processes in this form works well for management processes, which are essentially very iterative, it is not so good for more traditional, sequentially based processes, where there is less iteration. The UK’s Prince2 method takes a similar role based approach for the management aspects. Oddly enough, the UK’s Managing Successful Programmmes method (MSP) is rather muddled on this point, with the Senior Responsible Owner and Programme Manager roles combined in single processes, thereby losing the very clarity the roles are meant to promote. The PMI’s process set is more difficult to use in an enterprise approach, as the strong distinction between ‘sponsoring’ roles and ‘managing roles’ is missing. For example, in PMI’s PMBoK, the processes are all aligned around the project manager, with no processes for the project sponsor role. Further, the method makes little distinction between ‘phase’ and ‘project’, making it weak in the areas of starting projects, starting stages (gating) and closing phases and projects. You will also find the distinction between ‘portfolio’ and ‘programme’ emerging in many methods currently being written. The logic is that a portfolio may comprise both projects and programmes. In practice I have not always found this approach helpful. Taking it to an extreme, any programme which has sub-programmes immediately becomes a ‘portfolio’ and so, presumably, if this happened during the undertaking of a programme, the leadership team would suddenly take on a new set of ‘roles’ (e.g. portfolio manager) and use a different process. The distinction becomes rather academic and I have found the ‘business programme’, as used in this book, serves both the portfolio and programme use. Business programmes can have ‘sub-programmes’, and projects can have ‘sub-projects’ or be grouped into ‘project portfolios’ under a single business case. Too much definition and too many processes will restrict you. Keep things simple and open. Programme and project management are simply effective ways to manage certain types of work and should not be a dogma to straitjacket organisations in the face of common sense.
Process framework – the component parts
The processes are described as follows.
Direct and review business programmes
The purpose of this process is to ensure the organisation has a defined strategy and business plan, so that the business plan is segmented into discrete and manageable business programmes and appropriate targets are set. The business programmes should have as few interdependencies as possible; however, where such interdependencies exists, they should be managed through this process. This is often call ‘portfolio management ‘ and is the accountability of the executive team.
Direct and manage a business programme
The purpose of this process is to ensure the targets for the delegated part of the business plan are met. This includes overseeing the full scope of work for the programme, including the project portfolio and any non-project work, to ensure the required benefits are realised. The roles of business programme sponsor and business programme manager are key in this process. Two important elements, which relate to project management are:
- identify the need, which is the means by which new projects are initiated (see Chapter 5);
- undertake post implementation review, which is the means by which the effectiveness of a project is assessed (see Chapter 11).
Approve/terminate a project
The purpose of this process is to ensure each stage of the project is started in the knowledge that the project is still required, has a viable plan and the risks are acceptable. In addition, the process is used to suspend (place on hold) a project over which there are doubts as to its viability and, if necessary, terminate it (see Chapter 15). I have not presumed who the decision makers at the gates should be. In practice, most organisations create a table with a list of criteria and who has the delegated authority to make the decisions. This is very organisation specific.
Direct and manage a project
The purpose of this process is to ensure the business objectives of the project are met through the efficient and effective creation of the project outputs and deliverables. It comprises a number of elements:
- Directing a project, which is undertaken by the project sponsor to ensure the business interests of the organisation undertaking the project are paramount.
- Initiating a project, which is undertaken by the project manager, supported by the team, to ensure the project is properly set up and planned (see Chapter 19).
- Controlling a project, which is undertaken by the project manager, supported by the team, to ensure each stage of the project is managed throughout its life.
- Closing a project, which is undertaken by the project manager, supported by the team, to ensure the project is closed, whether because it has been completed or because it has been terminated early (see Chapter 27).
Managing delivery
The purpose of this process is to ensure the deliverables from the project are developed to the right quality, within the cost and time constraints. This process is undertaken by the team manager, supported by the project team members. Specialist processes would be used for undertaking the work itself.
Project frameworks
In Chapter 3, I proposed that a single project framework is used across the whole organisation and that this is tailored to reflect the different types of project undertaken. The advantage is that, top-down, all projects will look similar to senior management, who will invariably have to sponsor many different types of project. It also simplifies the roll-up and collation of portfolio reporting (Chapter 17). However, I have come across organisations that have a number of different project frameworks, with different names and stage numbers. These tend to cluster different types of project around the different project frameworks and as such have a number of different reporting systems and process sets. Usually they arrive in this situation because that was where they started; different parts of the organisation had their own methods and did not want to lose their ‘independence’. I have never seen an organisation arrive at this approach ‘by design’. That does not mean the approach is wrong, it is simply different and can be highly effective as long as the organisation accepts the additional overhead that multiple systems and processes leads to. However, do keep in mind that projects are there for a purpose and do not slice project frameworks up on disciplinary lines: I still see this with ‘IT projects ‘ under an IT Director and ‘business projects ‘ under ‘business directors’. When will they learn?
Supporting processes
In addition to the above management processes, there are a number of supporting processes, which I have shown on the right of Figure B.1. If I was running an organisation, I would not want each separate area within it using a different approach to risk management, for example. The supporting processes are there to ensure that all the techniques which are essential for effective programme and project management are used by all role holders at all levels. This simplifies reporting and communication dramatically. It also enables you to have a more cost effective tools strategy. Most of the topics essential to project management are contained in this book; however, you may wish to add others, to reflect the needs of your organisation. As examples, I have included ‘manage quality’, ‘manage purchasing’ and ‘manage documentation ‘ in the list. Others you may consider are ‘manage defects’, ‘manage transition’, ‘manage stakeholders and communications’, ‘manage reporting’ and ‘manage planning’.
Tailoring is the key
Not all organisations will want exactly the same set of processes and it is possible to assemble these in a number of different ways in order to emphasise different approaches or reflect an organisation’s culture. For example, in Figure B.1, I have shown the gate requests going from ‘Direct a project’ as I have taken the view that as it is the project sponsor’s project, he/she is the person who should make the request. This approach emphasises the role of the project sponsor as a leader, rather than letting them abdicate the role to the project manager. Other approaches may show the gate request going from the project manager, after verifying it with the project sponsor. Neither approach is better than the other; they are ‘differently right’ and a matter of choice. However, one thing you must make sure of is that you maintain consistency across your process set. If you were to take the MSP and Prince2 methods ‘as is’ you will find there are some different concepts and language used for the same things – they are not mutually consistent. You need to make them consistent by tailoring them and adapting your process flow and language accordingly. In this respect, the UK’s Association for Project Management’s (APM) Body of Knowledge has an extensive glossary of terms, many with commonly used alternatives. You will find the same happens if you base your approach on PMI’s portfolio, project and project set; taken raw, they will lead you to create a process set of extraordinary complexity!
Useful references
The following are the most prominent project management organisations in the world:
APM – Association for Project Management
The APM is the UK’s professional body for project management. Whilst it started with the traditional heavy engineering style projects it has made great strides to widen its appeal to all industry sectors, including general business projects. Its latest Body of Knowledge (5th edition) is an excellent reference of project management terms.
IPMA – International Project Management Association
This is an international body representing about 45 national associations. It is very active in certification, training and conferences and has a very enthusiastic following.
Office of Government Commerce
Home of the United Kingdom’s Office of Government Commerce (OGC), which has some 2000 pages of resources for you to pick through, review and adopt!
MSP – Managing Successful Programmes
http://www.ogc.gov.uk/guidance_managing_successful_projects.asp
Managing Successful Programmes (MSP) is the OGC’s structured and flexible framework for managing programmes. Unlike many approaches it makes a clear distinction between programmes and projects. MSP’s ‘programme’ is very close to Project Workout’s ‘business programme’.
PRINCE2
www.ogc.gov.uk/methods_prince_2.asp
The official website for the UK’s most prominent standard methodology. If you are in the UK and working with the public sector, you cannot ignore this.
Project Management Institute (PMI)
This is the USA’s association for professional project managers and the source for the USA’s standard. It is well established with chapters all over the world. The USA has a different approach to project management than that which is emerging in the UK and Europe, there being very little emphasis on the importance of sponsorship.