It is possible that all of us have attended Project Management Exhibitions and have been impressed with the array of very sophisticated technologies available for our PMO work. The vendors demonstrate the software engineering elegance; it looks so easy to drive these powerful tools, with their array of functions that seem to satisfy all of the organisations requirements. One of the key features that fascinate me is the diagnostic capabilities, which help you to pinpoint the cause of the problem, and in some case may offer a suggested action.
On some occasions it is like tuning an old car. No on-board computer, just the vehicle’s inter-linked mechanical components, which have to perform and are liable to fail. It requires making careful and attentive adjustments with a screwdriver to the carburettor – watching the rev counter, listening to the engine pitch, looking out for changes in exhaust fume colours and watching the water shake in the glass balanced on the engine block. Maintaining the car helps it to perform, be economical and road worthy, or reliable and safe.
So thinking about the investment of enterprise project management solutions, which many PMOs seek out in the quest for real-time, accurate data, sometimes it can lead to disappointing outcomes. Many organisations set out to see a quick return on their investment and will look for quick wins. However when the returns are not materialising it’s time to look deeper into the root causes.
As part of the investigation it makes sense to talk to the stakeholders in the ‘project’. These are the people who will use the tool.
Enter the Programme Manager. “It’s like when you take your car to a garage to have a routine service. Then the service representative calls you at home and says that the diagnostics have indicated that there are a lot of things needing replacing and in their opinion the car is beyond economical repair and that it should be scrapped.” So our Programme Manager is not a great fan.
How about the Business Manager? “I need straight forward support from the PMO, not people who are hiding behind their tools. I want somebody who knows when and how to use these tools. They have so many tools they do not know what to do with them. For me the PMO must understand the use and intent of the tools.”
The work stream leader. “One of the biggest issues is getting the resource managers to commit their resources to our plans. The use of the new tools have just exasperated the original problems, we have more demand than supply. The PMO keep on saying to me, these features can help you. The PMO must focus on adding value. They need to recognise that some of our underlying processes and procedures e.g. resource management are immature and do not match the sophistication of the tools. We need to get back to the basics.”
How about the project analysts in the PMO?. “We have only made the problem worse for ourselves, we should have standardised the project and programme data, even basic time and cost standards and rules would have helped. This would have enabled us to get the quality based upon simple compliance. We could then build upon some stable foundations.”
What about the opinion of the Project Managers?. “We have not even agreed ownership of the tools within the organisation; it is obvious the PMO owns them. They also have the responsibility for instructional training, optimisation and promoting how best to use them. They have to know how tools should be used, when and when not to use them.”
And finally the CIO, “We went through the requirements gathering; vendor selection and proof of concept, but the vendor took the lead. We underestimated a number of things; we were dealing with organisational change, maturity, and competencies of individuals in the PMO. We were seduced by all those features and the PMO did not try to temper our ambition.”
The worse case scenario has been revealed, a depressing state of affairs at worse or an opportunity to address the grievances.
It makes sense to find out what the CIO really needs from their PMO. Moving the tool to one side for a minute, the fundamental question should be:
“What technical competencies must the PMO have?”
In this case the organisation needs PMO mechanics not service representatives. The PMO need to be able to set-up the programme or project based upon the governance requirements, provide a service at regular intervals and run health check diagnostic as required.
PMOs need the skills and experience of a seasoned mechanic who has some grease under their nails, as this is all about practice not theory. They must be objective and realistic and be prepared to work with their customers to develop considered repair / recovery options, before the final is decision is made to scrap the project.
PMOs need to get back to the basic stuff, the technical stuff: scheduling, resource and cost management etc. It is for the PMO to understand and know what is going behind the calculator buttons of that very powerful tool.
PMOs therefore need to focus on improving their technical competencies first, ensuring they are competent in the areas that the projects and programmes require.
This is not just undertaking education and training in core project management fundamentals but taking that learning one step further and saying, “What is the PMO angle?” Take planning as an example. PMO can take a project planning training course, yet when they return to the office they are not planning projects, they are not the Project Manager. So what angle do they need to take with the project planning knowledge? Is it creating good planning standards? Is it creating a template or tool? Is it running workshops to help others in the business plan well?
PMOs have to Find out how to use their technical competencies in the right way and at the right time. They also need to address the fundamental concerns their stakeholders have. It is only when the PMO is able to do both of these that a tool can be introduced to make good practice become faster and smarter. Otherwise the PMO are just mechanics using a sledgehammer to open the bonnet.