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.
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.
Old News for us might be new news for the mainstream. In future posts you’ll see some older stuff popping up again, that is (hopefully) nevertheless relevant for the months ahead. if you don’t like it, or it’s already “old news” for you – just skip it.
HP Laboratories published some research back in January 2009 on revealing actual interactions among people of massive online social networks. The example of social interactions within Twitter reveals that the driver its usage and exploding growth is a sparse and hidden network of connections underlying the “declared” set of friends and followers.
The new Strobe framework builds on the vision of the Open Screen Project, a broad industry initiative to deliver a consistent runtime environment across desktops, televisions, mobile phones, and consumer electronics. While this might be a game changer for over-the-top video, I wonder how DRM and existing IPTV platforms will react on this.
