Tweet

A few years ago, a meticulous research study of 860 Project Managers (whittled down from 5,258 PMs) and 4,398 of their stakeholders was undertaken.  Called ‘The Alpha Study’, and led by Georgia-based Project Manager and author Andy Crowe, one of the aims of this landmark study was to try to define the qualities that made an ‘Alpha’ Project Manager more effective than any other. Crowe published the findings in his book, ‘Alpha Project Managers (what the top 2% know that everyone else doesn’t)’, which challenged many of the assumptions in the profession of project management today.

Essentially, the assumptions of the PMs were tested against those of their stakeholders, and perhaps not surprisingly, it turned out that most of us are making incorrect assumptions about what our stakeholders want and how we should relate to them.  Interesting too was that only 18 (2%) of the study group were identified as Alphas – 6 female and 12 male, a close approximation of the gender split across the whole study group. 

Crowe discovered that Alpha PMs were the ones who consistently delivered projects that met the project goals, managed stakeholder expectation, and kept the customer, the team and the organisation in harmony.  And whilst it might appear obvious that naturally, an elite PM would be achieving results like these, the reality is that most PMs find it simply impossible.

‘Alpha Project Managers’ is interesting, and has attracted discussion from all sides.  But importantly, it encourages you to think about how you manage your own projects. I’ve extracted some quotes for you to read, but if you’d like to read more, it’s available from Amazon in either hard copy or ebook format.

EXTRACTS FROM ‘ALPHA PROJECT MANAGERS – (What The Top 2% Know That Everyone Else Doesn’t)’  by Andy Crowe

“Today, the project management world is awash in solutions ranging from software to maturity models. to methodologies, to training courses. This would be fine if we all agreed upon and understood the problem.”

Aim of the project:  Transfer equity investments held for clients to a new entity

Constraints:  A data migration was not possible and the project had to close out of the market and then transfer the holdings to the new entity.

History:  The project was scheduled to take 10 months and was highly governed and reported.  Several external reviews were held and these relied on apparent compliance with governance structures, project practices and reporting.  All of these consistently showed green.

Review:   At the eight month mark the Board sought yet another independent review but this time from the perspective of actual readiness.

Findings: 

• The paper trail and meeting records were detailed and compliant in every respect
• The project manager was a nervous wreck and he tried to reconcile the picture available through compliance and what he ‘felt’ about the project.
• Escalation by the project manager was responded to with platitudes and assurance that it would all be ok.
• The processes allowed that the people involved would be able to be held blameless if anything went wrong
• There was a general nervousness at the worked level on the project and a frustration that those above them weren’t listening to the actual problems and risks
• The project team felt isolated by the governance and reporting
• There was a deal of ‘intellectual avoidance’ being applied where niggling questions and unresolved issues were not pursued.
• There was no tolerance for raising and exploring dissenting views
• There was a history of dissenters and people asking for additional resources to be removed from the project
• There was no evidence that testing was or would be adequate, escalation processes were not in place, there was inadequate highlighting of the extent of the risk and that there was no possible fall back position.
• Inadequate thought had gone into the reputational and market risk associated with the project and the people at the very top of the organisation were not at all aware of the risk that was being accepted. (There was no way to mitigate the risk but there was seriously inadequate effort applied to making sure decisions were being made by the people and at the level where responsibility was held)
• There were examples of decisions being taken at the technical level without visibility or involvement of the people whose decisions they would rightly be.
• It was not possible to assess that the actual project was under control – in spite of the governance and compliance being actively adhered to.

Remedy:

• Held a meeting with all project team members from top to bottom, including the sponsor and walked through what would happen from the time go/no go was called.  It became immediately apparent that there was a lot of work to do in a number of areas – not just the IT readiness.
• Appointed people who would each be responsible for the new operating model, training, customer interface, management expectation setting
• Went to daily war room meetings
• Involved the board and apprised them of the risks and explained the mitigation strategies as well as the potential actions required of them should risks be realised.
• Moved to a ‘truth in reporting’ model for within the project – external reporting to the PMO continued to be compliant with requirements (no one wanted the PMO to try to help out)

Outcomes:

This was a very successful project with the risks not realised and the go live running smoothly. However, it would have been a very different story if the project processes and reporting had remained as the only check point.  Project management had forgotten the paperwork isn’t the project – something had to be delivered.

When complications arise in the heady world of banking, especially the unpredictable business of planning out equity investment transfers, there’s no option but to calmly tackle the project from the ground up, look to those core issues to find solutions and disentangle the twists before they become knots.

 A key element in the success of this project was continual focus on delivering the required outcome, and of course this should always remain an outstanding PM’s manifesto.

Don’t forget to share your comments on this or any other related topics – I’d be interested in hearing from you!    … Diane

Case studies are useful reference tools for PMs. They allow us to examine and better understand a project path, in effect, what happened and why.  They also allow us to analyse and identify real-life, real-time problems, and in doing so,  the how, why and ’what the?’ questions are more easily isolated &  unravelled.  Of course no project, program or portfolio follows the same path, but the hindsights of thoroughly researched case studies enable us to implement effective solutions and  improve best practice strategies.  I encourage you to comment on this biotech study – send me your thoughts! 

Aim of the project: New product to market.

Constraints: Sensitive to:

• Time as the company was aware of a competitor’s progress in the same direction
• COGS as the company needed government reimbursement (in all global regions) to get adoption
• Regulatory because of the FDA and other national and regional regulatory bodies.
• Market as the release date had been announced to the distribution channels (with the effect that orders for the current product were slowing down and sales channels were teasing the market with the new product)
• Share price as failure to deliver to expectations could wipe significant value off the company’s value.

History: The project had commenced two years earlier and was nearing the release date (three months out). The CEO was worried though as he ‘smelled’ a problem. All the project reports were showing green or amber and the budget was totally on track.

Review: My role was to review the project for the CEO and provide comfort or suggestions for moving forward.

Findings:

• The project was being managed under an adaptation of Prince II (meaning there were stage gates and approvals prior to moving to the next stage)
• In today’s language it was really a program rather than a project as it involved projects from engineering (electrical, mechanical, software), clinical, marketing, regulatory, manufacturing etc
• There was a tilt at earned value in as much as they knew what they should have spent by when.
• The project manager held weekly update meetings and updated the plan to reflect where they were up to.
• After watching the project for one month, it was clear that no progress at all was being made – except spending on schedule.
• Risks were being recorded in a ‘risk register’ but there was no active mitigation
• Everything was waiting for one activity that simply wasn’t progressing
• The reports and updates were all being done but progress had completely stalled.
• People on the project were completely comfortable with this as the process called for sequential effort and they were committed to not breaching the process (ostensibly for regulatory reasons)
• Everyone on the project loved the PM – a totally accommodating and understanding fellow.
• Because it was such a large and long project the one monthly stalling had not yet crossed the 10% variant tolerance
• There was absolutely no movement or idea about how to unblock the stalled part – it was as though they were waiting to break the variation tolerance so them they would know what to do.
• Estimated that left as it was, the project would complete at least 12 months later than predicted.

Remedy:

• Replaced the PM with someone who looked forward rather than simply reporting from a ‘rear vision mirror’ perspective.
• Removed the linear approach so all other parts of the project could continue (there was no actual dependency on the stalled part for at least six weeks)
• Introduced progressive integrated testing rather than testing only as planned at or near the end of development
• Installed some urgency via reporting on actual progress as against schedule for spending
• Suspended stoplight reports (RAG) in favour of reporting what was actually supposed to have happened by when
• Disallowed all % complete reporting and insisted that something was either done or not done (this introduced a level of discomfort that caused push back but was insisted on)
• Reworked the deliverables so there were clear achievement points (black and white) well ahead of the overall activity completing
• Brought together the people who could solve the ‘problem’ that had been ‘holding up’ the program – and solved it quickly once the right people felt free to contribute
• Focussed on the core requirements of traceability and regulation
• Orchestrated a coming together of the project elements at the right time rather than a linear arrival.
• Reforecast the project adding 16 weeks – and additional funding as the budget had been being spent without progress
• Delivered on schedule (as reforecast) – to the bewilderment of the project team and the original PM
• Reworked the implementation of Prince II to accommodate the desirability and benefit of parallel activities.

Outcomes:

All regulatory, clinical, testing and compliance requirements were met. The product remains in the market and there have been no recalls or problems outside the industry and company accepted tolerances.

I just have to have a bleat about people who espouse project management approaches when in fact they ‘know nothing’ (said with Hogan’s Heroes accent).  I have decided once and for all that there is a massive difference project management and project execution.  Once upon a time, management could expect that a PM would deliver an outcome; now it seems all too often that PMs are simply mystified when, having done everything by the book, the project is a mess. Perhaps there’s something wrong with the book?

 The Rocky Flats Story

Rocky Flats was a very contaminated nuclear site in Colorado.  The Government decided to close it and repatriate the land.  Experts were called in and the project budget, success criteria and timeline were planned and approved – 70 years, USD36bn and a prescribed level of residual contaminant. Over the next few years not much happened and the Government replaced the Program Director – inspiration or good luck – it was a great move!

Everyone who hears about Rocky Flats will take away their own lessons, but here are the ones I took away.  Perhaps nothing new but wonderful to have reinforced that ‘you know, this stuff really does work!’  So, to the lessons as interpreted, understood and remembered by me.

 1.      It’s all about the people. At Rocky they shared the 100 million bonus with the ‘hourly staff’, unprecedented and brave, and very effective!

2.      Use the culture of the organisation, not the one you think it should have.

3.      Focus on a period or achievement pot the project – at Rocky they focused on the new jobs that each person would have after the site closed – a major project in itself as Rocky was a very large local employer where it was common for 3rd generation workers to be there and to have expected their grandchildren would work there too. A lot of effort was put into working with the staff for their personal future.

4.      Afford all people dignity – but that doesn’t mean they get to stay.

5.      Remove people who are either openly or passively aggressive.  Do it quickly and don’t worry about loss of domain knowledge even if the people are the perceived top performers or critical to the operation.

6.      When you remove troublesome people, cooperative people will come out of the woodwork – they’ve been waiting for a chance.

7.      Don’t tolerate bullying – no matter who is doing it.

8.      The program director doesn’t need domain knowledge – they need to be able to get the best out of the people you’ve got.

9.      Use symbolism and ceremony to communicate support and change.  At Rocky the admin building was demolished at the start and the admin and government staff moved into the buildings with the ‘nuclear’ staff, and the most senior management moved into trailers on site – providing a very clear message that this was indeed temporary.

10.    Ask the staff what is the best solution – the staff came up with a solution that was 60 years and 30bn less than the experts planned.

11.    Give the people what they ask for to achieve the job – if you truly want the outcome. At Rocky, as part of closing the site, the workforce almost doubled in the first couple of years of the program. That is, the first few years once the new Project Director was in place.

12.    The only absolute rule was safety first.

13.    The sponsor has to be brave and constant, and ready to move any and all obstacles.

14.    Once success is in sight, don’t review the budget & time and hope for cheaper, quicker – the deal was already good. At Rocky, this was tried by the stakeholders and effectively fought off.

The bottom line is – it’s about the people. If you look after them, they’ll look after you.  The researchers who watched and recorded the phenomenon called it “working in the abundance gap”, and that’s pretty much what it was.

The site is now repatriated, just under schedule, a few hundred k under budget, having exceeded the residue limit by 13 times (in the right direction).

I hope I’ve managed to convey some of the wonder of what was achieved. It reminded me why I went into this profession and why I stay to help out companies. It’s really rewarding!

I’m also glad I’ve met people along the way who have endorsed the approach and let me manage projects in the abundance gap.

Keep smiling, the best thing about projects is, there’s another one  coming and another chance to be excited.  Don’t you love it!