Case Studies | By Mike Griffin | minute read
A project manager's prime task is managing a project to success. The products of the project need to be picked up by the line organisation, and if this involves change in the organisation or ways of working, the changes must be made to 'stick'. By ensuring that the responsibilities for project management and business change are well assigned in a project there is an increased chance of success.
In all projects assigning the correct project manager is crucial. The choice is often not simple. I have experienced this in the form of a dilemma: do we appoint someone who is an experienced project manager or someone who will champion the change? Very often the experienced project manager will come from a technical background, e.g. IT, and will not have authority to make changes in the organisation or processes. On the other hand the change champion will have credibility with the business unit, but often not have the project skills required. If you can always find all of this in one person, then good luck to you; you don't need the rest of this article!
When Is This a Problem?
There can be a problem in a project that is not part of a programme. Let's look at the differences between programmes and projects. I'll use MSP™ (Managing Successful Programmes of the OGC) to illustrate. MSP clearly differentiates between projects - that deliver outputs - and programmes - that deliver outcomes. The main difference is that a project that is not part of a programme delivers the output to the line organisation; the line management is subsequently responsible for achieving the benefits (outcomes). A programme, on the other hand, is also responsible for the benefits realisation of the projects within the programme.
I have noticed, in our organisation at least, that projects are expected to deliver the change in the organisation, so the outcome is not achieved if the project only delivers the output.
How Does It Go Wrong?
To ensure a good mix of business change and project management, for IT projects, we have in the past staffed projects with a project manager from the customer, a "business PM" or BPM, and an experienced project manager from IT, the "IT PM", reporting to them. This can work well, depending on the individuals and how well they cooperate and complement each other. But if the BPM doesn't have the required project management capabilities there can be a conflict of authority: the BPM is in charge - the "boss" - but the IT PM needs to tell them what to do and how to do it. Hoping that the BPM and IT PM will complement each other and work well together is not enough, we have seen this go bad a large number of times. Roles and responsibilities, especially for the project management tasks, is the foundation of a project and if that goes wrong it is very difficult to correct. So it's best to get it right at the start. Having more than one person in a project with a role of "project manager" is confusing. There should only be one. This can be resolved by only giving the overall project manager this role and the IT PM is called an "IT work stream lead" or "IT team lead". Some IT project managers have great difficulty accepting this; after all it says "Project Manager" on their business card, and they expect that to appear as their role in every project as well. Of course a project role and a job title are completely different things, but we have found that this "role inflation" has crept into the way people see project roles. My goal was to ensure that when a project was setup, it had a good foundation to be successful. Of course the project team members still need to work together well to be successful, but giving the team a good foundation allows them to focus on delivering together, instead of trying to work out who they should listen to. I started looking for a solution to this dilemma.
What Did I Find?
My analysis led me to the conclusion that we needed a capable and experienced project manager to be responsible for the project management, and someone with the right authority and "organisational credit" to be responsible for the change in the business. As the experienced project managers available for our IT projects are nearly always from IT they do not have the authority or credit in the customer's organisation. And the main customer contacts, the potential candidates for the BPM role, often don't have the project management capabilities. Looking at how MSP describes the programme structure, the key players are the SRO (Senior Responsible Owner), the Programme Manager and the BCM (Business Change Manager). The key here is that the BCM does not report to the Programme Manager or vice versa; and that the Programme Manager is responsible for the day-to-day management of the programme while the BCM is responsible for delivering change and benefits. Why couldn't this work in a project as well? With a team of project managers I worked through the roles and responsibilities in a typical project, with the aim of making this work. The project managers were motivated in this too, as they had experienced the problem first hand! The result was a proposed project structure as shown in figure 1.
To explain to the Steering Group, other stakeholders, the project manager and BCM how the responsibilities are split over the project manager and BCM, we have also developed a RACI matrix and a standard role description. These are then discussed by the project manager and BCM, and if necessary the sponsor, at the start of the project. They are then tailored for the specific project, but have proven to be an 80-90% fit at the start.
Does This Work?
We have now started a number of projects this way, and the project manager finds that it gives clarity on the main roles at the start of the project. Also, there is little chance that the BCM will try and run the project, normally they have their hands full with the business change anyway! So the BCM is happy to know that there is someone else responsible for the day-to-day running of the project. A number of projects that started with this structure have completed, and the feedback from the customers has been good. On review the project managers feel that this approach works well, and also gives enough room for tailoring to the needs of the individual project.
This problem only occurs in projects that are not part of a programme, but in my team we have a large number of these. Having a project manager and a BCM, with clear responsibilities and the capabilities to match, greatly increases the chance of success in the project team. I am aware that this is probably not the only way to solve this dilemma, and would like to hear from people who have other ideas and experiences, even if they are contradictory to mine!