If you’ve ever watched the movie “Office Space”, then you know that one of the reoccurring themes throughout the movie is the reference to the TPS report. Most of us realize the correlation between the fictional report and the weekly status reports that our project leads require from us. The leads then paste our work into their status reports—only taking time to take out strong wording, bold print and/or re-shading the color scheme.
Meanwhile other teams within the organization are filling out their weekly status reports and going through a similar process. I’ve often wondered that if the world ended on a Monday what would your weekly status report look like to the leadership team on the following Friday after going through all the layers of upper management? I believe it would read something like this:
“Project status yellow - Small hiccup on Monday to the XYZ project with a majority of the staff taking the day off for personal reasons. However, a plan has been put in place to get us back on schedule by training the increasing population of rodents and insects to supplement our resource retention issues.”
Setting proper KPIs
These reports are partly fueled by the high-tech tools that some project managers may employ such as Microsoft Excel. These tools review inputs and then create key performance indicators (KPIs) graphs—which we realize is all subjective and KPI’s really stands for “keep projects invested”.
What leadership needs is real time inside (where the real work is done) with the ability to set thresholds and progress indicators that are not subjective. It would be best if the thresholds were based on productivity and quality.
Application Lifecycle Management version (ALM) 11 and 11.5 has the answer for you. These versions have incorporated a new tool in the arsenal of true performance indicators (TPI’s) with the creative name of “Project Planning and Tracking” or PPT which offers:
- Planning release scope and objectives and their expected progress throughout its duration
- Monitoring release quality, progress and productivity with respect to the objectives
- Up-to-date release status visibility to stakeholders
- Mitigating risks and adjusting objectives based on status and on changing circumstances.
This tool is specifically designed around specified thresholds that are identified at the beginning of a project or release. It uses scorecards graphs and detailed reports to convey results. While a lot of tools use things like issue logs, percentages and other watered-down calculations, these key TPI’s uses the actual data accumulated during every phase of the development process (design, build, test and implementation).
True knowledge is power
You are probably thinking that this takes a lot of preplanning and design. Luckily all you really need to kick off this process in ALM 11 and 11.5 is the ability to:
- Set release start and end dates
- Defining the scope of application requirements, change requests and identifying the assets that will be created or developed to support those items
- Notate the possible risk of the project which then allows you to adjust your thresholds during the release
- Defining milestones and associating them with scope – this determines the release activities
- Planning objectives per milestone – by setting TPIs and thresholds
Most of that information can be derived from the project plan or directly from the requirements and change requests for any given release.
Release Performance vs. Plan
The whole concept is to move away from subjective measurements of the project’s releases progress and move to the quality of the real health of the release. The best marathon runners mark landmarks along the course and then estimate the amount of time will take them to reach that landmark; this keeps them competitive while being realistic. These aren’t subjective but instead are based on past performance and the environment and they give the runner a true picture of his current situation within perspective to the overall race.
It’s the same with monitoring your current release. The key is to ensure that the release’s quality and progress are as expected. If there is deviation of the actual release performance from the plan the release manager can analyze the root cause and take mitigating actions as the deviation occurs.
The figure below shows a sample scorecard. The rows are release features and the columns are TPIs. The TPIs are grouped by the milestones (release stage) on which they are measured. The circled cell, for example, represents the test execution status on the ‘Online Recurring Booking Service’ feature.
The question is “What would you do if you didn’t have to fill out a weekly status report?” Instead project leads showed up at your desk asking how they could help. This all happens before you end up working through the night because you’re the only one felt the urgency of the situation. The other side of the coin occurs at the beginning of the project. Imagine if someone asked you how long it would take you to perform one testing cycle. You estimated a month and instead they gave you two weeks—how would you measure your success?
If you’re currently on ALM 11 or 11.5 are you currently using the PPT calculator? What do you think? If you are using older version of Quality Center, do new features like this and 11 & 11.5 make it worth your time to upgrade? I want to know what you think, let me know your experiences in the comments section below.