45

Playout Intelligence

Project Management: What’s Critical?

measurements beyond deadline; define discreet boundaries for green, yellow, red status as % of plan deviation; keep list critical issues sorted by project delay

The saying goes that after more than two hierarchy levels of reporting, every project status becomes green because nobody likes to fail his boss. In my early years of consulting, when I was still glad that I didn’t have to do any status reporting, I experienced a lot of projects, where “meeting the deadline no matter what” meant everything. The first thing that went was functionality. If that didn’t work, quality of deliverables was reduced, and if the deadline still seemed to ambitious, we worked frantically through the night. All the time, the project status was at most a tish yellow, but never red. And it wasn’t even a lie: there was always something delivered at the due date.

I recently worked on a strategy project that was part of an Identity Management program at a tier 1 telecom operator and experienced the same thing again. The first milestone of the program totally bombed: everyone delivered in time, but all executives were dissatisfied with the result. When reviewing with the program management office what went wrong, we discovered that there were very little tangible measurements in place other than “do we make the deadline” – which is by the way a very binary question: I wonder how you can meet the deadline half without any other measurement such as work packages, time, resources…

What’s Measurable?

We came up with a couple of measurable items that worked for us:

Overall program goals
Work package progress
Resources used such as people, software, hardware, etc.
Person days billed against the plan
Preconditions of the program environment such as buy-in and support from key executives, basic program assumptions, strategic and tactical goals, support from other consultancies, vendor relationships, etc.
Number of overall documents
Number of infrastructure locations
Involved divisions
Levels involved in planned change management and number of steps necessary to implement change
Number and severity of risks

How To Measure?

While some of the things from the previous list are relatively easy to measure, such as the number of documents or divisions involved or person days billed against the project. Others are more tricky: How do I assess the severity of risks? To what degree is a program goal currently satisfied? Do we measure work packages by the number of sub-tasks we finished, or by the difficulty of finishing these tasks?

Our solutions were very straight forward:

When a work package starts, set the progress indicator to 20%. When it finishes, set it to 80%. When it was reviewed by the steering committee, set it to 100%. We used the same methodology for the overall program goals.
Measure the number of days the project will be delayed when a risk, change of assumptions, or change in preconditions of the program environment occurs.
Measure the resource impact when a risk, change of assumptions, or change in preconditions of the program environment occurs.

For each of the measurements we then defined boundaries of percentages of the planned values for different status levels. For example, for issues, risks, and other events that popped up during the project, everything that delayed the program more than seven days was a yellow item, everything more than 21 days was a red item. You get the picture.

The Dashboard

The result was a steering committee dashboard, covering time, resources, work in progress, and a list of items and events each with its impact on time and resources attached. It told the committee where we were right now, and where we would be if we kept the course. Now the steering committee was able to take actions: revise the plan, call in people who could help, or take other counter measurements. The dashboard was never intended to directly stop or change work packages, or make strategic and tactical decisions, but to support the steering committee in these tasks and revisit the plan, making decisions and issues transparent.

 

2 Responses

You can follow the comments for this article with the RSS 2.0 feed.

Hello Guru, what entice you to post an article on l Status Reporting in Project and Program Management | Playout Intelligence? This article was extremely interesting, especially since I was searching for thoughts on this subject last Saturday.

1 Netflix Work Environment May 03, 2008 11:45 am

Thanks for sharing this post

2 Project Management Methodology July 27, 2009 3:47 am

Leave a Reply

Required fields are marked with an asterisk (*), you may use these tags in your comment: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

blog comments powered by Disqus

Recent Tweets

Archives

Content © Playout Intelligence
Proudly powered by WordPress
Theme designed by Artisan Themes

Entries (RSS)
Comments (RSS)

31 queries.
0.606 seconds.

Creative Commons License
This Playout Intelligence blog post by Thorsten Claus is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

All entries in this blog are my opinion and don't necessarily reflect the opinion of my employer or sponsors.

Except where stated, all materials contained in this Web site are the copyrighted property of Thinkstorm. Permission is granted to use, copy and distribute these materials as presented in this Web site for personal, non-commercial use only. All copyright and other notices must appear in all copies as they appear in the original. All other uses are prohibited. (please also see these two articles about “All Rights Reserved” and general copyright law, with some focus on the US).

This site contains links to other sites that are not owned or maintained by Thinkstorm. These links are provided for your convenience. Thinkstorm makes no warranties about the contents of or products and services offered by such sites.

Thinkstorm shall not be liable for any injury, claim or damage whether direct or indirect which arises out of the use of this site or its contents or the inability to use this site. Thinkstorm shall not be liable for any injury, claim or damage whether direct or indirect which arises from the unauthorized access to or alteration of your transmission unless it results from the gross negligence or intentional actions of Thinkstorm.