12 Steps To Design And Deploy A Project Management Framework

A project management framework is a consistent approach to the delivery of projects in an organisation. It normally consists of a common project lifecycle, defined roles and responsibilities, key documents and a set of governance rules. The advantage of a framework is that is encourages

1. Continuity because that project teams and members have a shared understanding of what is required at each stage.
2. Communications because defined stages and documents help people understand what stage to project is at and what needs to be done next.
3. Consistency of delivery because projects are guided to follow the principles of project management.
4. Improved governance because the framework defines the rules for the initiation and control of projects.
5. Clarity over the delivery of the project roles, responsibilities and processes.

The challenge with a project management framework is to design in flexibility to accommodate the wide range of projects experienced in many organisations, from the smallest to the most complex.
In our last post we described what is a project management framework. In this post we describe twelve steps to creating and employing a project management framework. So what are the stages to go through when designing a project management framework?
So what are the stages to go through when designing a project management framework?

1. Create an owner for the framework and empower them
2. Understand the current level of maturity and range of projects in the organisation
3. Define the levels of governance for different projects
4. Design a simple lifecycle with stages and gates
5. Define project roles and responsibilities
6. Define key gate documents and templates
7. Define a simple but effective reporting process
8. Walk through the framework with a project or two with key stakeholders
9. Check integration with other processes such as business planning, finance and procurement
10. Create a brand for the project management framework
11. Conduct a road show and listen to the feedback and organise training in the framework and supporting competences
12. Monitor and review

We have discussed all of these in turn and provide some pointers and thinking around each. We have also included a checklist that helps trigger thoughts about some of the key decisions to be made when embarking on this framework development.
We have also drawn up a sample project plan for implementing a framework, the times are flexible but the activities are quite sound.

1.    Appoint an owner for the framework and empower them.

The implementation of a project management framework (PMF) is just like any other project, and should be run just like any other project. It can however be useful to establish a project management office to own the PMF long term, to share lessons learned and support the reporting and governance arrangements. We recommend the appointment of a ket business sponsor who will provide the leadership and direction and bring together the inevitably disparate views of the various stakeholder groups.

2.    Understand the current level of maturity and range of projects in the organisation

Before starting to design a PMF it is useful to understand the range of projects that will be supported by the framework, from the largest to the smallest, from the most successful to the biggest failures. Any framework should be designed to accommodate all these projects. It is usual to begin with a complexity assessment tool and this then can be used to drive which documents (or which parts of documents) need to be used. It will also be helpful in directing when reviews will be needed and at what level of the organisation. A ‘one size fits all’ is a noble ideal but is rarely able to fulfill its promise. Assuming the PMF is successful the organisation will want to use it on all projects, so it is best to design this in from the start. Analysis of complexity can become very complex and so the organisation must agree these rules (see the checklist).

3.    Define the levels of governance for different projects

Not every project needs the same levels of governance. Some smaller project can get benefit from simplified documentation or stage gates. Different levels of project will need different levels of authorisation. A key output from a framework is guidance on how to apply the PMF to different types of project. This is normally done on either level of finical authority or complexity. As mentioned the complexity assessment at the start is useful for this aspect, but it will invariably require tuning and adaption to suit multiple scenarios.

4.    Design a simple lifecycle with stages and gates

A gate is a point at which the project has to seek authority to proceed to the next state. These are based linked to approval of funding. The stages define what is done between the stages. You can have several stages between each gate, but normally a stage produced a document that is approved at the next gate, such as a business case or a design. It is best to use stages that have meaning and resonance in the organisation. This may seem more easy that it is. Getting approval on a set of terms, names etc, is usually fraught with problems as the business will usually have already used terms that it is used to and then again different parts of a large organisation will usually have their own different versions of a so called ‘corporate’ standard. Almost as soon as orgainstions have a framework someone will add the suffix ‘lite’ to it. Try to keep is as simple as possible but scalable and open to enhancement.

5.    Define project roles and responsibilities

A project needs defined roles and responsibilities. These need simple but clearly defined responsibilities. As a minimum these include, Project Board, Project Executive (or sponsor). Project Manager and User, but for small project this may be too complex. In larger organisations it may be necessary to think about the links to Programme Managers and Portfolio Managers. This one aspect is usually the most sensitive as it crosses over with people jobs roles and functions. Keep to defining roles rather than names. Use generic terms like ‘authorising body’ ‘Project Champion’ etc. People change but the role will remain.

6.    Define key gate documents and templates

The next step is to define the key documents and templates needed at each stage. People love forms for here. A long hand document can be great but they are more difficult to complete. Some may already exist in the organisation so it can be a matter of culling the existing templates. Using a standard template will be a change for some and business as usual for others. It is unlikely that any suggestion will completely fit the bill and satisfy everyone. Try and be flexible and instill the idea that it is a framework and not a method.

7.    Walk through the framework with a project or two with key stakeholders

We would recommend completing the templates for a range of projects from the smallest to the largest projects and publishing these as model documents. Doing this as a walk through with stakeholders is a good way of getting key players involved. Once published the completed templates act as effective guidance for those who are using the framework. It is very important to develop a small but authoritative and knowledgeable group who can be the ‘disciples’ in the business for the use of the framework. Writing something in a back room and trying to roll it out will fail miserably. It will not be adopted and fall quickly into disuse.

8.    Define a simple but effective reporting process

Most PMFs have a highlight report. Often this is collated by the PMO into a monthly report to the team executives. Try to keep this simple and think about the frequency of reporting, maybe not every project needs a report every month. Maybe a rolling 3-month programme will do. Be pragmatic about this. It is not essential to hold rigorous scrutiny over a small low risk, low value project that is being well managed. Allow flexibility in the mode so that valuable time can be used to its best effect where it is needed most.

9.    Check integration with other processes such as business planning, finance and procurement

Often a PMF has integration with other core processes in the organisation such as business planning or procurement. Make sure the PMF aligns with these processes. Are the authorisation levels consistent with procurement? Are the gates aligned with any tendering process? Is the information in the business plan carried over into the project brief and business case? Make sure that any proposals do not contradict or interfere with normal business processes. You are not trying to re-engineer the entire business, make sure the scope of what you are doing is clear and everyone buys into that.

10.Create a brand for the project management framework

By now you will have a collection of flow charts, PowerPoint slides, templates and excel sheets. It can be very helpful to summarise these as a PMF documents and employ a graphic designer to help present this in an appealing way to your PM community. This should be simple to understand and follow the core messages you which to communicate. You can always provide the detail on an intranet website.

11.Conduct a road show and listen to the feedback and organise training in the framework and supporting competences

You are now ready to go, after all this work then it is worth getting some senior stakeholders to present it to the project managers and sponsors so they understand the benefits and importance to the organisation. This does not need to cover the detail, just the why and what I have to do. Quite often the implementation of a PMF will require new skills and competence in the project management community. This is where training can help people get up to speed with the new skills to support the framework. It can also help people consider the benefits of a project management framework and how it can be applied to their project.

12.Monitor and review

As a project management framework beds into the organisation then the user community will see significant areas for improvement and it is worth listening to these and updating the PMF say one a year. It is highly unlikely that a new untried and untested method will be completely successful first time around. You should make sure that there is plenty of time and resources about a year down the track to review it and to produce updates. Particularly if you are proposing things like estimating metric or lessons learned into the mix.

Useful Questions to Ask

 

1. Are roles and responsibilities in the business clear when it comes to projects?
2. Are the rules about who has what authority – to do what easily transferred to the project space?
3. Are the people who do governance actually competent and do they have enough time?
4. Are the staff actually knowledgeable enough to engage with a framework and the concepts implied and embedded within it?
5. Is there a clear roadmap for specific types of projects and will it be possible to implement a single life cycle across the board
6. Is there a design group able to input to, review and ultimately approve the framework once it’s written?
7. Is there sufficient budget to cover all of the aspects needed (Workshop, drafting, review, publication, roll out, training, refresh, support structure, time for reviews, assurance, etc.)
8. Is there a likely way that project assurance will be implemented, having a framework is one thing, ensuring it is used appropriately is another.
9. Are there threshold criteria that are used to escalate significant issues, risks and opportunities through the organisation to the board and is there a receptive cultural approach when that happens?
10. Is there a clear perception of the benefits to be gained across the business? Will it actually be worth it?
11. Is there an appetite for the change in the business, do they recognize the value?
12. When highlight reports are written who will review them and what will they do then?
13. Is there a clear view of what a problem project and what a very good project looks like? Is the business able to articulate the category RED and what happens then?
14. Is there suitable access to tools to support the framework, are you asking the teams to use particular software that will cost a lot of money to implement?
15. What will happen if the framework is too successful? Is there a follow on exercise planned to maximise the good bits and de-scope the not so good parts?
16. Is the business ready to implement the roll out as a change programme in its own right? The framework implementation is a project just like any other; is there enough resources to ensure that it is properly implemented?
17. Have you thought about training, who will do it, how many people, when, resources, facilities, etc.
18. Who will be the executive sponsor for it?
19. Can a lot of time and effort be saved by simply adapting work already there or by using a publically available method (like Prince2).
20. Does the business culture encourage open and honest reporting?

Parallel Project Training has helped many organisations, large and small, to develop and deploy effective project management framework. Don’t start this project on your own, get in touch and we can point you in the right direction.