Tweet

The following guide to using the RACI model was prepared by John Elsworth, a project manager with many years experience delivering in Finance and Banking, Biomedical and transport industries.   It took RNC 5 years to convince him to join us and we are very glad that he has worked with us now for 5 years….  

Managing stakeholders is vital to the success of a project and one of the most challenging aspects of project management.  Have you ever been looking for a single project tool that would help with stakeholder management; the communications plan; developing peoples’ roles and responsibilities; and, creating project delegation authorities?

The RACI model can be a valuable input to these elements of planning particularly in the early stage of the project when you are writing your initial version of the PMP.  This stage of a project can be very confusing when you are juggling so many stakeholders & project members. In our line of work as contract PMs we are typically just getting to know everyone too.

Of course, like all elements of planning, the RACI should be an interactive process and updated as appropriate to the project needs.

People who participate in creating/updating the RACI model enjoy it as they get a lot out of it and it can be fun & thought-provoking.

The RACI is an effective communications tool because stakeholders and team members find it intuitive and easy to digest.

So, how does a RACI work? The output is a matrix of responsibilities of all the stakeholders and members of the project team. Their job titles are assigned a letter depending on their role in the project. RACI is an acronym and the letters represent the level of participation in the project –

•  R is for Responsible (the do-er of the activity)
•  A is for Accountable (the buck stops here)
•  C is for Consulted (typically an important stakeholder or a subject matter expert)
•  I is for Informed (someone who needs to know … or wants to know but they are not an active participation in this particular activity)

The matrix should have the project participants’ role title on the horizontal axis and the project duties/activities on the vertical axis. The letter of the RACI which best represents their roles & responsibilities are allocated and placed in the appropriate cell co-ordinates.

The RACI matrix can become a great friend to a Project Manager. Project planning can be time-consuming and complex. The RACI matrix helps dissect information into simple, bite-size chunks.

Let’s look at a quick example. The hypothetical project is the design and manufacture of a new hybrid car which must have regulatory approval from the government.

It is advisable to highlight the cells where the “A” and the “R” appears as these are the most important. Also, it is helpful to make it visually appealing so it stands out for the reader above the other noise they encounter during their work day. For the PM, the colour coding helps with quality assurance, e.g’s. there should be only one “A” allocated in every row; &, the “R’s” should be well distributed across the stakeholders/team-members.

Please note:
i.    Once drafted, the matrix should be placed on formal review.
ii.   Note that the RACI can include external as well as internal parties. In this example reference to the Regulatory Authority is an external organisation.
iii.  Logically in the hierarchy, the A is the highest followed by (in order) the R, the C, and the I. Will leave it to you to spell that out!

After syndicating/agreeing the RACI with stakeholders, the project manager has so much information they need to work out the “who”, “what”, “how’s” and ”when” for the elements of the project planning mentioned above.

There are a number of variations of the RACI model and these can be applied according to the nature of the project –

•   RASCI model – includes provision for a support function
•   RACI-VS – includes 2 participation types for verification and support
•   CAIRO – uses “O” for omitted
•   DACI – where “D” represents the driver of the project activity

Anecdotal story
I once distributed my draft RACI and got feedback from a stakeholder that he wanted to have a “C” (consulted) against all the project activities. Indeed he was an electrical engineer and wanted to be consulted on all the other engineering disciplines as well! Nevertheless the RACI was a great basis for a constructive conversation with this person and I learnt a lot about him at the same time, which was useful as the project matured.

Further Reading
Project Management Institute: PMBOK Guide, Edition 4 -
http://www.pmi.org/PMBOK-Guide-and-Standards.aspx

Wikipedia - http://en.wikipedia.org/wiki/Responsibility_assignment_matrix

Project Management Essentials - http://projectmanagementessentials.wordpress.com/2010/02/02/nn-12-formula-for-number-of-communication-channels/

We’d like to hear from you. If you use the RACI model, post a comment or send us your feedback.

Portfolios Programs Projects – simply making them happen

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!