It's Not Easy Being Green

So far, we've covered the reasons for using a color code system of red-yellow-green for reporting status.  We've talked about what constitutes a project in red or yellow status.  Now it's time for the impossible... the unattainable... the unthinkable... the only-in-your-wildest-fantasies-not-including-the-entire-stadium-made-of-chocolate-dream:  a project in green status.

OK, it's really not that hard to achieve green status, but given the multitude of things that can go wrong on a project, it's also not easy to achieve green status either.  And it really takes very little to veer a project away from being green.  For those who are curious about how to achieve Project Utopia...

Scope

• Have the requirements been fully defined and converted into workable tasks at the appropriate level of detail?
• Is scope being managed (complete with a solid change management plan)?
• Are quality checks and signoffs integrated throughout the plan?
• Is rework virtually non-existent?

Schedule

• Is the team following a baselined project plan?
• Have the critical path and major milestones been identified, and is the project team managing project operations with them in mind?
• Are tasks and activities on schedule with virtually no slippage?

Resources

• Has the project budget been defined and baselined?
• Are funds and resources available when needed to adequately keep the project moving forward?
• Are there virtually no cost overruns?

Other Factors

• Is your team fully functional with few cultural or political impacts?
• Is there strong, visible sponsorship?
• Is there an operational risk management plan in place?
• Is communication predictable, usable, and ongoing?

Obtaining status green should not be that difficult, if you have done due diligence in the Initiation and Planning phases to ensure the project starts well.

Before we leave this quick-and-dirty tour through the project color spectrum, I have a couple of questions that generate good old-fashioned debate in project circles.  I honestly am curious what you think:

1. If any element of your project status is red, should the entire project be placed in red status, or is yellow good enough to express the color?
2. Should any project be allowed to be green during the planning phase, given that no baselined project plan is in place?  (On this one, I think I'm the lone voice crying in the wilderness.  My take is that a project must earn green status by completing the planning phase.  Allowing a project to be green during planning does nothing to motivate a team to complete their project plan baseline.)
3. Who owns the decision to set and to change a project's color?  Is the project manager or the project sponsor ultimately accountable for determining this?

Your views?

Old "Yeller"

Sigh.  It's the same old story.  Boy meets project.  Boy learns to like project.  Project protects boy from evil corporate surroundings.  Project falls sick, threatening those around it.  Boy must decide to put project out of its misery.  Tears stream down boy's face as he raises his shotgun and...

Oops... sorry.... I started channelling classic Disney movies again...

How do you know when your project "gits the hydrophobia"?  (For those who haven't seen the movie, go out and rent it and then reread this post.)  Many projects are ailing and on various roads of sickness.  Knowing how to identify the signs of a project in "yellow status" will take you far in identifying the true status of your project:

Scope

• Is the Project Plan incomplete or not baselined?
• Are scope changes not reflected in the most current Project Plan?
• Are quality checks and regular sign-offs missing?
• Is undocumented rework occurring?

Schedule

• Has the project plan been rebaselined (i.e. a do-over, a mulligan) due to slippage or poor estimation?
• Is significant yet recoverable slippage of schedule occurring (less than 10%)?

Resources

• Has the project budget been loosely defined (e.g., hitting the side of a barn)?
• Is it difficult to procure funds and resources when needed?
• Are significant yet recoverage cost overages occurring (less than 10%)?

Other Factors

• Are signs of stress noticeable yet still manageable?
• Are there problems with project commitment from relevant executive stakeholders or are office politcs playing a more prevalent role than planned?
• Are more risk events occurring than originally planned?
• Is communication sporadic or inconsistent?

Yellow is probably one of the "easier" status colors to report.  You don't have the pressure of justifying green.  You're not under the magnifying glass of red.  People expect things to go wrong.  However, yellow status is not an invitation to become complacent.  Yellow can turn into red in the blink of an eye.  Just keep your project away from rabid, wild animals and nobody gets hurt.

Red Rover, Red Rover, Send Status On Over

OK, so we've established that determining the color of status reports creates a certain level of political spin doctoring in some organizations.  And no color seems to cause the most problem than red.

I once worked in an organization where the Chief Information Officer was a very early morning person.  Starting at 5:00 AM on Fridays, he would hold "sunrise services" in his office for any project manager whose status was red.  Rumor has it that these were not pleasant meetings, but to be fair to the executive, the projects were on his radar and he was discussing the root causes that created the red status and often providing his assistance to alleviate the situation.

How can you determine if your project is seeing red?  The process that has worked well for me over the years is to break down the project into four sections, as follows:

Scope

• Are there random scope changes or a considerable amount of unchecked scope creep?
• Is the project plan non-existent or just plain ignored?
• Is more than 10% of the functionality or requirements still in question?

Schedule

• Is there no project plan baseline (i.e., nobody has finalized and approved a project plan)?
• Has there been a schedule slippage of more than 10%?

Resources

• Is the project budget non-existent
• Is it next to impossible to procure funds and resources when needed?
• Are you experiencing unrecoverable cost overruns of more than 10%?

Other Factors

• Is the team exhibiting signs of distress or dysfunctional behaviors?
• Are the sponsor and executive leadership weak or absent?
• Is there an absence of a risk management plan or is the project under constant seige from unplanned risk events and issues?
• Is most of the communication absent or fictional?

If you are answering YES to any of these questions, then it's time to face the facts and come to reality.  Better to be red in the project than red in the face.  And just because one factor from the above list is red does not necessarily make the entire project red; one should consider all the factors before determining if red is the overriding project status.  These factors are just a few of the common ones to consider.  By breaking your project down into the basic components of the triple constraint, it becomes a little easier to isolate the factors contributing to the color status.  Hence, if you ever get called into a "sunrise service" you can be a little more prepared to communicate proactively with your sponsor.

Next stop:  Yellow Status

Can You Taint With All The Colors of The Wind?

I was in a status meeting one time where we were all going around the table, talking about our projects and sharing what color status they were (red, yellow, or green).  The project manager who was sharing his story was on a truly disastrous project, so it was an amusing point of synchronicity that a squad of firetrucks came blaring by the building as he was reporting the disastrous existence that he was experiencing.  I congratulated him for expressing exactly how badly his project was going with well-timed sound effects.

It's an amazing phenomenon in the project world that three simple colors - red, yellow, and green - can cause such consternation among project managers, project teams, and executive leadership.  Take this case study in spin doctoring as an example.  Tahmid Munaz of SQA Bangladesh shares an amusing story from an agile newsletter about color shifting.  The simple version is that the project team wanted the status reported as red, the project manager played it safe and reported yellow, and senior management put on their perceptual filters and reported green.  Hence, it appears that the stoplight is broken... very, very, VERY broken.  The question then becomes, "How can we fix it?"

The color of project status - be it green, yellow, or red - should not be a challenging consideration.  What amazes me is that these three colors throw everyone into a tailspin.  I've seen project managers turn into Martha Stewart ("Can we report our status as 'lime' since we're not quite green all the way?" or "I'm not quite ready to report us as red... is 'pumpkin' an acceptable choice?").  It would appear that reporting red-yellow-green is one of those cross sections between project management and office politics.  So... the next three posts will be dedicated to helping all of you project managers out there in the blogosphere determine what color your project really is.

By the way, Dan Wahlin had an interesting post last month about tools that would allow one to report color status in a dashboard.  While tools are fine and dandy, it is equally important to understand WHY you are choosing the color you have so you can justify it later.  Still, it's a worthwhile read.

SHARP Status: Projections

I was waiting at Panera for my communications consultant, Mike Sansone, to arrive.  I was grateful he was running late because I was able to eavesdrop on the following conversation between a young 20-something bride-to-be and her grandmother:

Grandma:  Honey, you need to be focusing on your shoes and your flowers and get those ordered.

Bride-To-Be (incredulous and somewhat disdainful tone):  I've got four pages of tasks and you're telling me I only need to focus on two things?  Besides, I don't need to do either of those things until the end of March.

Grandma (deadpan voice):  Honey, that's next week.

Bride-To-Be (lightbulb dimly illuminating):  Ooooooooooooooooh.

If you have focused on creating a good project plan, documenting the PROJECTIONS of the tasks to be completed in the upcoming reporting period should be a non-event when creating your SHARP Status.  Again, I refer to Robert McIlree and his March 15 blog entry.  He says a key question to ask your project sponsors is to have them define what "done" looks like.  So simple.  So astute.  That single question helps you back into all the "next steps" you will need in order to carpe factum.  What's next leads you to what's done (i.e., should be reported in ACCOMPLISHMENTS in your next status report).  While HIGHLIGHTS give readers the long-term future view, PROJECTIONS provide the short-term future view.  Just like our overwhelmed bride-to-be, many project managers fight that plethora of tasks, so it's to their benefit to give stakeholders a heads-up on what absolutely has to be done next.

So... there you have it... the five components of a solid SHARP status report.  One or two pages.  The right details.  The right frequency (preferably weekly).  The right audience (who cares or at least should care).  All done.  Carpe Factum.  Now give yourself a pat on the bag and get back to work.

SHARP Status: Risks

We all have risks and issues to deal with.  Show me a project manager with no problems with people or any area of the triple constraint and I'll show you an irrelevant buffoon.  How you handle the speed bumps in your project raceway is your problem; how you communicate them is of broader concern.

I'm becoming a quick Scott Berkun fan.  His February 13 Post:  The boss who won't listen, demonstrates why the Risks section of the status report is so critical.  The dilemma Scott raises in this post about risking the wrath of another manager by raising an issue is indicitive of our anti-carpe-factum organizations.  They are so concerned about being nice, or avoiding any political faux-pas, or making sure that one does not get one's backside singed, that they avoid documenting issues.

There once was a vendor project manager who reported to me on a complex software project.  There were a considerable number of issues that were hammered out during some very heated meetings over the course of one week, yet the issues and risks section of his status was blank.  When asked about this oversight, he responded that all of those things were "being handled at the executive manager level."  Irrelevant!  Those issues affected our project, and they needed to be documented.

Which brings us back to the point of this section.  This is your opportunity as a Project Manager to bring visibility and elevation to those risks and issues that are outside of your hands or above your head.  This isn't a forum to whine, nitpick, or tattle.  This is not your "Ruh-Roh... R'I'm Rorry, Reorge" moment to cry over spilt milk.  This is your chance to demonstrate some credible backbone and show that you are handling everything, but here are the impending things that could derail the project this week.  Then succinctly describe the risk or issue and your current plan of action (i.e., don't just tell them there's a problem; share your solution or next steps with them).

Also as a point of credibility, try to keep this section to NO MORE THAN 3-5 bullets.  As with other sections, document the ownership of the risk or issue.  Then use this section of the status in your next sponsor or steering committee meeting to launch into your talking points about the risk or issue.  Ideally, this section should like to a log where you are tracking risks and issues.  For the beginner, just gathering the bravery to put it in writing without the fear of "shoot the messenger" will be a good starting point.

So... is your status feeling SHARP yet?

SHARP Status: Accomplishments

Accomplishments.  The heart of a Carpe Factum Organization.  Firemen extinguish fires.  Performers take a bow.  Judges sentence criminals and make decisions.  Mechanics fix cars.  Project managers make check marks.  OK, so we do more complex things than make check marks.  We lead resources to get things done.  We complete tasks.  We achieve milestones.  This is the heart of the status report.  Each reporting period, a good project manager should report on what was accomplished in the prior reporting period.

As with highlights, ensure that you provide specifics on who accomplished the task and the appropriate details surrounding the task (i.e., don't go into excruciating detail about what you did - remember that executives... um... I mean, gnats can't focus much).  Also, do not report incomplete tasks as complete.  There is no such thing as "substantially complete" or "virtually done."  Don't report every single task on your project plan.  Focus on the important stuff, the top 5-10 that people will really care about.

Task accomplishment may not separate project managers from the other beasts of the field, but at the end of the day, it is the one thing for which we are ultimately accountable.  We can address issues, hold meetings, resolve conflicts, comfort stakeholders... but if we are not seizing accomplishments, we're just deluding ourselves.  We need to own the task, hold it down, beat it up, and steal its lunch money.  OK, OK... a little overzealous there... I'm calm.  But get out there and CARPE FACTUM.  And then brag about it on your SHARP Status.

SHARP Status: Highlights

When driving, it can be very challenging to be behind a vehicle larger than mine.  I can't see very far down the road, and I have no idea what lies ahead.  Project managers are faced with this dilemma every day.  We get caught in the issues, the problems, the risks, and the drama of the project.   It is difficult to see what lies down the road, let alone communicate it, when trapped in the "administrivia" of day-to-day project activity.

That is where HIGHLIGHTS come into play in a status report.  They allow project managers and our status-reading audiences to see beyond the day-to-day tasks and issues and look further down the road.  Providing that milestone look-ahead adds tremendous value to the big picture thinkers.

In the January 15, 2006 entry of his blog, Robert McIlree does an admirable job commenting on "The Worse Type of Project Manager" who is able to politicize better than he can produce; however, milestones don't lie.  When a project manager sets a milestone, s/he is communicating to the world a stake in the ground.  Still, in communicating milestones, I try to communicate a balance between flexibility and accountability by telling who owns the milestone, what the milestone is, and when it is expected to be done (note the word choice; saying a milestone is expected by a certain date rather than saying it will happen on a certain date leaves room for ever-present assumptions and risks).  Examples:

OK:  The test plan will be complete on November 15.

BETTER:  Tom will lead the QA team to complete the regression test plan, expected to be complete by November 15 (previously listed as October 31).

Not only can you use this section to list milestones; it is also useful for sharing pending or approved change requests.  Any major activity that impacts the long-term scope/condition of your project is fair game.

Remember:  This is your chance as project manager to set (and reset) expectations.  Be honest if you must move a date.  Be selective and communicate the milestones that are of greatest interest to your audience (key deliverables, critical path dates).  Let your readers see the road beyond the big hulking vehicle that is blocking your view with all the trivial day-to-day tasks, meetings, and issues.  Just one more way to keep your status SHARP.

SHARP Status: Statistics

I was reading an entry from Adam Bryner's blog entitled, If You Can't Measure It, You Can't Manage It.  Too often in service and manufacturing, ambiguous goals and directives are set such as "Increase customer service" or "Improve quality" in a feeble attempt to motivate workers.  Just as in any business, where every task should be linked to measures, so it applies to projects.

If you are like many people, any mere mention of quantitative statistics causes flashbacks to boring college math classes, resulting in a nervous twitch from too many excruciating exams.  (Breathe deep, find a happy place, and bear with me.)  Project statistics do not have to be complex and scary.  A simple collection of qualitative and quantitative statistics can provide a wealth of information to quickly and accurately diagnose the health of a project.

For qualitative stats, the project's name, project manager, and project sponsor provide ample identification.  Quantitative statistics include start and finish dates (actual and baselined), cost data (baseline, actual, remaining, variance), and effort hours (same as cost data).  If you are an especially adept project geek, you can include earned value (don't ask).

The trick is to be brutally honest on your project statistics.  "Baking the numbers" may prevent you from being scolded by an overzealous executive in the short run, getting caught baking the numbers means a damaging loss of credibility.

Finally, remember:  you are writing for multiple audiences; however, all stakeholders want to see impacts to cost, hours, and dates.  Just like checkbook balances and blood pressure, simple statistics can can inform those who care the most about the health of your project.  And that's just the beginning of writing a SHARP status report.

SHARP Status Reports

Status reports can be a challenging communication vehicle for a project manager.  I've seen status reports that are so sparce and cryptic that they barely provide basic evidence that a project even exists.  On the other end of the spectrum are status reports that would turn the average doctoral dissertation green with envy; it's a wonder that any work is done on the project given the effort that must go into creating such a communication beast.

Then there is the audience - those reading your status reports - which ranges from the highest level executive to the lowest level analyst.  The detail-mongers will demand more and more information, viewing any omission as some covert sign that you are hiding critical data.  The typical executive, however, has the attention span of a gnat (I probably should have kept that inside voice - now I'll get nasty emails from gnats everywhere for comparing them to executives).  In their defense, many executives have A LOT of competition for their attention.

In the next few blog entries, you'll be introduced to the 5 components that make up a good status report, and how better reports can be written for our projects.  This is where art meets science - that sweet spot where points of "carpe factum" can best occur.  A quick preview, these five components are as follows:

1. Statistics
2. Highlights
3. Accomplishments
4. Risks
5. Projections