How to Apply PRINCE2: Engaging Senior Management in Your Projects
The Project Board concept from PRINCE2 is an excellent way to get senior stakeholders involved in a timely manner. This article will firstly look at the theory and then look at how to put it into practice with some case study examples from Orgtopia.
The Project Board is a small group of people, no more than six or seven, who make the key decisions such as; should the project start, should it go on to its next stage and finally is it ready to end? There are three roles within the Board; the senior user, the senior supplier and the executive.
In each Project Board there is one Executive. They are ultimately responsible for its success. The Project Board is not a democracy; the executive has the final say in any decision, but is supported by the other two roles. They will see the project from a business perspective, so will be looking to ensure that it creates some benefits such as increased sales or decreased costs. They are often the budget holder. They should be high enough up in an organisation to have the authority to deal with any major obstacles. This is a key role. Good Executives are great leaders and display vision, clarity of purpose and great communication skills. Not coincidently the first two are also the characteristics of a good project.
A number of people on the Board will be Senior Users. They will represent those who are going to "use" the final product. There are a number of ways a product can be "used." For example, if the project was to build a new web site, there is direct usage, where key customers might buy services from the site. There is also indirect usage, for example the company's marketing department, who will "use" the site to drive up sales. All ways of "using" the products and services of the project need to be identified and represented on the Project Board. If there are a lot of users, then it might be a good idea to have a separate User's Forum that sends one or two representatives to the Project Board.
There will be one or more Senior Suppliers. They should have the authority over the people who will build the project's products or services. They could be internal or external to the organisation. For an IT project they could be the head of an IT department or an external software development company.
The idea of having the suppliers represented on the key decision making unit of the project is challenging for some people. Usually they are coming from a conflict-orientated mindset, where they are seeking to drive the hardest bargain with their suppliers. Of course it is important to negotiate a good contract between all the third parties involved in a project, but once these negotiations have completed it is key that all parties work together as a team.
So how do you apply this concept to put together a workable governance structure for a project? Here's some examples of how it's worked for us.
We worked with a pharmaceutical company on an Internet project. They were building a web site to provide drug information for doctors, nurses and health managers. The project idea had been around for many months, but continually failed to make it past the feasibility study phase. The main reason for this was there would be many direct and indirect users of the web site internally within the pharmaceutical company spread across the IT, Marketing, Medical Information, eMarketing and Transformation Departments. There was a lot of disagreement between all these groups about how the project should be run and what it should be about.
We suggested that we forget the debate about what should be built and focus first on working out who should fill the roles of the Project Board. This seemingly innocuous task took two months! We went round to all the people we considered relevant, presented the concept of the Project Board, and asked them to workshop with us who should go in the relevant boxes. We got a number of different versions but eventually came to an agreement.
What the process revealed was a power struggle between the IT department and the Business, both of whom wanted to take the key Executive role. Understanding this and resolving it at the beginning was key to the quick progress we made later on. Eventually it was agreed that the director of a Transformation would be the Executive, as they held the budget, and the Head of European IT, would be the Senior Supplier, as they would control key technical resources.
One criticism of this approach is, "Isn't it a waste of time spending two months just putting people into project roles?" This example was an extreme case; usually it takes a much shorter time. But if we had started the project before we got agreement on the roles, we would only had difficulties later on getting key decisions signed off. Also there would be the risk that we hadn't identified all the key users and not get a full set of requirements.
The other extreme is where no one wants to take on the Executive role. Working on a project for a UK local government body, within a six-month time period we'd had three executives leave the role. We began to understand that this environment had an unforgiving culture for mistakes. Taking on the Executive position was risky in case the project failed, especially as the organisation had a record of IT project disasters. We eventually worked very closely with the final executive to careful manage the risks and reassure them of the likelihood of success.
One other problem in this last project was that there were sixteen people on the Project Board. When people are unwilling to take on responsibility project boards tend to get large. Safety in numbers I guess! However there is definitely an indirect correlation between how many people end up on the project board and how likely the project is to succeed! We created two other subcommittees, one user forum who sent three people to the Project Board and one supplier forum, who sent two people to the Project Board. The result, a Project Board that could quickly make decisions rather than discuss them.
The Project Board concept is probably one of the best ideas within PRINCE2. I have seen it transform projects. It helps with better and quicker decision making, ensures roles and responsibilities are understood, successfully engages stakeholders, makes sure the right requirements are created and ensures that the project is properly aligned with the organisation's strategy and that it will bring real business benefits to the company. It is not always the easiest idea to implement, but a bit of time and effort at the beginning of a project to "train" the stakeholders in their roles, can pay large dividends later on with a successfully delivered project.
David Hinde is a recognised expert in management development and executive coaching in the UK. He founded Orgtopia in 2003 and since has helped many organisations such as the BBC, Citigroup and the British Army to develop and unlock their leadership and management potential. To view his original article go to: Prince2 in Practice: Engaging Senior Management in Projects
The History of PRINCE2
PROMPTII, PRINCE and PRINCE2 were all introduced to address the common causes of project failure by providing a better set of tools to deliver projects.
PRINCE2 2009: What's Changed?
PRINCE2 the UK's most widely used project management framework is being refreshed. The name remains the same, but there are some fundamental enhancements.
PRINCE2 Training Myths & Misconceptions
This article looks at five aspects of PRINCE2 to give you the clear, concise information you need if you're considering investing in PRINCE2 training.
PRINCE2 and the Project Management Board
The PRINCE2 project management method focuses on organisation, management and control, and teaches users how to form a Project Management Board.
Seven ABC's of Project Management:
- Always be Closing.
- Always be Courteous.
- Always be Considerate.
- Always be Cultivating.
- Always be Cognitive.
- Always be Competent.
- Always be Communicating.
Discover our online forum where you can ask questions, find out tips from other people and share your experience.