This case study explains how a QA team used part of CMMI to measure – and enhance – the success of a Prince2 implementation in the IT division of a large European bank. The choice of CMMI PPQA as the QA toolkit (rather than a Prince2 based QA toolkit) was advantageous, as it allowed the QA team to focus on the real PM process rather than the formal Prince2 process.
In 2007, my client’s IT division had a new project management process which it was struggling to impose. New and powerful tools for project management were proving hard to use, and were an additional barrier to process improvement.
There were around 500 concurrent IT projects in 7 portfolios spread over 3 countries, with about 130 PMs (project managers). Note the meaning of “IT” for the bank at this period: the “IT division” had responsibility for ICT infrastructure and operations; various “IS divisions” handled software and process change projects.
Management was very focussed on projects and wanted to drive PM process improvement. There was a major and vital IT transformation programme with an annual 20 million euro budget which was viewed as a vehicle for process improvement.
The PMO for IT was large (normally between 8 and 10 people), with the equivalent of 2 people working exclusively on PPQA. In mid 2007, most of the team worked on coaching and training – in 2008, the focus turned increasingly to other tasks (reporting, resource management, etc).
The bank was implementing project management as a process in IT and IS, based on the Prince2 process model. There was top management support for project improvement using defined processes, with KPIs to measure the process.
The decision was taken by IT in early 2007 to use the CMMI PPQA process area as the model for process improvement and therefore for providing the KPIs to measure progress.
What is PPQA?
PPQA is one of the 22 process areas in CMMI. In broad terms PPQA intervenes in the project process to
• Perform periodic project audits to assess compliance
• Help teams get back into compliance where needed
• Find opportunities to coach and improve.
A series of metrics was agreed with management, about 30 metrics per project, addressing 3 levels of project management maturity. Each individual metric was fully defined, both in terms of its process objective, and also the evidence to be examined to decide whether a project was compliant.
For each portfolio, a large and representative number of projects was selected, for example 40 projects out of 100 for the infrastructure team of 25 PMs. We sought to assess at least one project per PM.
An audit procedure and the PPQA assessment schedule was published and agreed with management (middle level IT management and portfolio managers). The analysis of a portfolio took between 2 and 4 weeks total elapsed time. The whole iteration for all portfolios took 3 months.
Each selected project was assessed by the PPQA analyst. The PPQA analyst published intermediate results, giving the chance for an appeals procedure and/or for corrections by the PM; and then final results. All results were stored and consolidated.
Results were communicated to the PM, to the portfolio manager; and in summary (consolidated form) to middle and senior IT management; and to the group.
Statistical analysis showing improvements in time over successive iterations was highly useful in motivating teams to participate in improvement activities
Overview of the 4 iterations
2Q07 – mixed results – drove improvements in the process documentation and training content
4Q07 – significant improvements in compliancy – boosted credibility of the project improvement initiative
2Q08 – assessment very focussed on Prince2 – emphasis on common process within whole group
4Q08 – new assessment model – truer measure of IT project compliance – actionable results
Why we used PPQA and not a Prince2 maturity assessment
We used PPQA as our toolkit for QA. This gave us a generic approach where our assessment was a measure of the effective process in use (and not just of the Prince2 textbook process). For example, a key part of the process was entering and maintaining accurate data in the PM tool. This is not part of Prince2, but was part of the process we measured. Equally, IT management stressed the validation of the project mandate, and again this is not part of Prince2, but was one of our key measures in PPQA.
In the 3rd iteration, in spring 2008, to satisfy group requirements, we used an assessment which was highly focussed on Prince2. This assessment generated the least useful data of all 4 iterations, as it missed so many essential process elements. This iteration was a negative “lesson learned” – it confirmed to us the advantage of using our “generic” CMMI PPQA approach against a Prince2 maturity model (based on the OGC P3M3 model)
In this large IT team, the process area of CMMI called PPQA was successfully used as a tool to measure and improve project management process compliance (even though the process that we measured was based on Prince2 rather than CMMI).
Reference: Project Management Success with CMMI, James Persse, Prentice Hall 2007
Prince2 and CMMI are trademarks of their respective owners.