In a previous post, I laid out some of my rules for implementing a RAG status, which when used with discipline, can greatly help in project communications especially with demystifying areas or workstreams for your project team. I would still recommend any aspiring project manager to learn about the RAG status, it has become part of project management lore, and tradition in some organisations, where people expect to see some kind of RAG. Familiarity is good, but don't be too pedantic about it!
I am not so sure about RAG any more...I've come to love-and-hate the RAG...It's a tool that I impress on my project managers to use, but I feel less inclined to use the RAG in upwards-communications. Of course, it depends...
I've been running projects for close to ten years now, starting with the usual small pieces of work, 3-6 month projects, 2-4 teams, one customer; then moving on to large teams (20+) scattered around the world, multiple projects with multiple teams, 12-24 months projects. So I've come to appreciate the softer side of management, to the extent that, RAG status is almost meaningless to people not responsible for managing projects or workstreams. You can waste a lot of time justifying why you as a project manager (PM), have settled to communicate the status using the said-colour (say Red), and that it is entirely within your right as PM to use your judgement, after-all, it is something that you gotta deliver!
Managing stakeholder expectations is key to the success of any project, ultimately the stakeholder is happy that his/her expectation has been met. This is a little challenging especially when there's multiple stakeholders who hold the same pecking order in the org structure, and are contributing teams to a unified project, multiple departments coming together to deliver a huge feature, end-to-end. Getting consensus at this level is always troublesome, do you really want everyone to buy-in to the why you communicate a project's status?? You can of course try, get them together, talk them through your flow-charts and state models, explaining what "On Target - Risk" means and why it's Amber, or what does "Slipping - Not Yet Mitigated" Red means, or "Slip but expect to Complete" Amber means.
You can even explain how your Excel / MS Project Gantt includes the twenty odd sub projects tracking every single detail, bubbling up to each milestone, and how you run macros to determine if dates are being met, exceeded, and the algorithm you use to group individual task-level RAG items up to represent the group status of a parent milestone (and explain why you might have some Red tasks, but overall the milestone is still Amber or even Green). You could even explain your Critical Path items, PM 101 discussions, explaining why "Red - Slipping not yet mitigated" is a call to action for the stakeholders to actually do something, to help you recover things that is potentially beyond your control...
I've been through this a few times. Heck, I even have to explain, why as a program manager I refuse to use MS Project, and stick to Excel and other visualisations to track workstream plans at milestone level, the high level, rather than rolling in all twenty workstream plans into a massive Gantt that will end up being pages and pages long, with close to a thousand line plan. Instead I like my pretty pictures, work with individual workstream owners to manage their own internal plans, and rely on them to feedback progress against my high level plan. If stakeholders want to know the detail, I call it the PM/Owner, I don't want to know everything that goes on - this is micro-managing, something that I abhor, although this doesn't mean I don't know what's going on, or have no idea of what the work entails...A Program manager without an understanding of what the work entails doesn't go down well in my books, below are some snapshots of high level timelines from past projects, that I prefer:
It can be terribly frustrating and a waste of energy to win people over. Unless you've kicked off the project explaining the rationale behind controlling, tracking and reporting the project's progress, and the Steering Committee have signed off in terms of its usefulness thus relying on the RAG to be as close to reality as possible, and unless you have people who appreciate that a RAG is indeed valuable - I have come to learn, the hard way, that sometimes you just don't need to bother with such things.
Use it for your own purposes of course, so you as a PM are aware of the streams and how they're progressing. Take pains to maintain discipline about assigning the states, but use your judgement to extrapolate to the bigger picture, the wider audience, i.e. the stakeholders that matter! I have over the years managed projects without relying on following the RAG to the letter, relying more on my judgement, intuition and reliance on the teams to know what they've committed to delivering, the team will do their best to recover slippages, the plan isn't at risk, people have it under control, so even though the date on paper (current date exceeds original planned date, slipped by 5 days), so what?? There is still bandwidth to recover, dependent teams are alright - no need to flag as Red thus potentially destroying the morale of the team, increasing the spotlight on them, for their senior managers to come down hard on them!
That said, every project has it's own context - and some customers are really hard, and will impress adherence to generating a RAG and following to the letter. Make sure you understand the context and expectations up-front, sometimes a PM just has to pick his/her battles wisely, if people expect a RAG even though you think it's pointless, just do it anyway if it's not too burdensome, there will be other battles worth fighting and winning than getting hung up on what the RAG means to you, versus what the stakeholders see it.
Example, recently I had to adjust my RAG convention in the context of associated Risk & Level of Input/Help required from stakeholders:
I've been through this washing machine cycle many times, so much so, that one day, I will start out a project with everything turned upside down, i.e. all streams in the Red until turned Green!
Rants aside, some organisations have learnt how to manage projects the hard way, and have built up their own internal body of knowledge, streamlined their own management processes, and will have set up their own Project Management Office (PMO), some have setup an Agile PMO (!) - in these instances, there is generally wisdom behind these RAG statuses, that people will come to appreciate over time. I too have been found guilty of making premature remarks as a young project manager, just come-out-of-development, questioning everything I was asked to do...it was only through practice, discipline and patience in staying the course, that you grow as a project manager, appreciating after-the-fact, the sound wisdom behind such processes!
Real-world War Story
Going back and thinking about how I've come to have this love-hate relationship with the RAG status, below are snapshots of a project, as part of the program team, was responsible as Delivery Owner for a highly complicated software product, Set Top Box Middleware - distributed component software development model, across a few countries, all working together on individual components that had to be integrated into a cohesive product. We ran timeboxed-iterations, every 6 weeks, delivering features one-at-a-time (agile), these had to be carefully coordinated. I took over the reigns on Iteration 18, and handed the baton over on Iteration 46 (that's twenty eight, six week iterations, of 30 days = 840 working days). So you could say that I spent roughly 800 work-days, living and breathing, tracking and controlling the daily, weekly, mid-iteration, end-of-iteration statuses. In each iteration we averaged around 25 features. Each feature on average, say, would impact 7 teams. Each team had to be tracked. So we had to track on average, 7 x 25 = 175 work items daily. Each item on the plan was subject to the RAG status check. 175 individual RAG items had to be summarised into 25 feature-level-status RAGs. The feature level RAG had to translate back up to the overall product backlog RAG - if we slip features from one iteration to another, we will risk the program slipping. On a weekly basis, we had to send a report to the customer, closer to launch, we had to send more frequent updates.
Below is a picture from one iteration, a snapshot in time - remember I had maintained this thing daily for two years. The picture on the left is a RAG for the internal consumption of our team, the picture on right is the RAG that went out to the customer. Notice the translations - internally we maintained a sense of urgency (which was quite intense), externally we had to soften the communication by basically only using Red for things outside of our control, that we'd got prior approval to slip the feature out of the iteration.
Of course I had to find a way to make this repetitive task quick-and-easy for me. I had a powerful Excel spreadsheet, full of macros that tracked the feature backlog for the iteration on one level as a backlog, followed by detailed task tracking sheet that captured planned versus actuals, summarising the RAGs for internal use, had macros that then generated the RAG tables as above, with another macro converting the internal status to customer-friendly view. These were automated as much as possible, and shared on SharePoint project portal for all to interact with.
Real-world War Story
Going back and thinking about how I've come to have this love-hate relationship with the RAG status, below are snapshots of a project, as part of the program team, was responsible as Delivery Owner for a highly complicated software product, Set Top Box Middleware - distributed component software development model, across a few countries, all working together on individual components that had to be integrated into a cohesive product. We ran timeboxed-iterations, every 6 weeks, delivering features one-at-a-time (agile), these had to be carefully coordinated. I took over the reigns on Iteration 18, and handed the baton over on Iteration 46 (that's twenty eight, six week iterations, of 30 days = 840 working days). So you could say that I spent roughly 800 work-days, living and breathing, tracking and controlling the daily, weekly, mid-iteration, end-of-iteration statuses. In each iteration we averaged around 25 features. Each feature on average, say, would impact 7 teams. Each team had to be tracked. So we had to track on average, 7 x 25 = 175 work items daily. Each item on the plan was subject to the RAG status check. 175 individual RAG items had to be summarised into 25 feature-level-status RAGs. The feature level RAG had to translate back up to the overall product backlog RAG - if we slip features from one iteration to another, we will risk the program slipping. On a weekly basis, we had to send a report to the customer, closer to launch, we had to send more frequent updates.
Below is a picture from one iteration, a snapshot in time - remember I had maintained this thing daily for two years. The picture on the left is a RAG for the internal consumption of our team, the picture on right is the RAG that went out to the customer. Notice the translations - internally we maintained a sense of urgency (which was quite intense), externally we had to soften the communication by basically only using Red for things outside of our control, that we'd got prior approval to slip the feature out of the iteration.
Of course I had to find a way to make this repetitive task quick-and-easy for me. I had a powerful Excel spreadsheet, full of macros that tracked the feature backlog for the iteration on one level as a backlog, followed by detailed task tracking sheet that captured planned versus actuals, summarising the RAGs for internal use, had macros that then generated the RAG tables as above, with another macro converting the internal status to customer-friendly view. These were automated as much as possible, and shared on SharePoint project portal for all to interact with.
No comments:
Post a Comment