The question, “What does Done look like?” was asked every week on the program that changed my life as a Program Manager. Rocky Flats Environmental Technology Site (RFETS) was the marketing term for the third worst toxic waste site on the planet. RFETS was a nuclear bomb manufacturing plant that was built in 1951, operated until 1989 and closed in 2005. I served as the VP of Program Management of ITC (Information Technology and Communications), providing ERP, purpose-built IT, voice and data systems for 5,000 employees and contractors of the Bomb Factory.

what does done look like

The term what does Done look like, emerged at RFETS and has served as an anchor for program management success ever since. By Done we mean the attributes of the deliverables that fulfill a mission and business use, measured in units meaningful to the decision makers. The challenge is defining these units of measure, assessing the deliverables against these units of measure, and taking corrective action to the work efforts when they don’t match.

Knowing what Done looks like is one of five principles of project success that answers:

  1. What does Done look like?
  2. What is the path to Done?
  3. Do we have enough time, resources, and money to reach Done as planned?
  4. What impediments will be encountered along the way to Done?
  5. How do we know we’re making progress toward Done?

Done is the starting and ending point for project success. Along the way, there are four supporting principles that enable project success.

4 measures of Done

Any project control system has units of measure that are meaningful to the decisions that have to be made. There are four of these measures that collect all attributes of every project in every domain. They are:

  • Measure of Effectiveness (MOE). This operational measure of success is closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions. Measures of effectiveness are:
    • Stated in units meaningful to the buyer
    • Focused on capabilities independent of any technical implementation
    • Connected to the mission success

Measures of Effectiveness belong to the end user.

  • Measures of Performance (MOP). This characterizes physical or functional attributes relating to the system operation, measured or estimated under specific conditions. Measures of performance are:
    • Attributes that assure the system has the capability and capacity to perform
    • Assessment of the system to assure it meets design requirements to satisfy the measure of effectiveness

Measures of Performance belong to the project—developed by the systems engineers, architecture or lead developer.

  • Technical Performance Measures (TPM). These attributes determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal. Technical performance measures:
    • Assess design progress.
    • Define compliance to performance requirements.
    • Identify technical risk.
    • Are limited to critical thresholds.
    • Include projected performance.

Technical Performance Measures define the technical goal or values at the end of a technical effort.

  • Key Performance Parameters (KPP). This represents the capabilities and characteristics that are so significant that failure to meet them can be cause to reevaluate, reassess, or terminate the program. Key performance parameters:
    • Have a threshold or objective value
    • Characterize the major drivers of performance
    • Are considered critical to the customer

The buyer defines the Key Performance Parameters during the operational concept phase of the project. It’s the KPPs that determine what Done looks like.

Time phased measures compliance

Each of the above four measures is also time phased with a planned value; so when compared to the actual value we see how close we are to the plan of reaching Done.

Figure 1 – Time phased planned Technical Performance Measures for Mean Time Between Failure and actual measures of MTBF for the product deliverable. Going outside the upper or lower control limit means the product is not compliant and the project cannot be on cost and schedule.
Figure 1 – Time phased planned Technical Performance Measures for Mean Time Between Failure and actual measures of MTBF for the product deliverable. Going outside the upper or lower control limit means the product is not compliant and the project cannot be on cost and schedule.

Figure 1 – Time phased planned Technical Performance Measures for Mean Time Between Failure and actual measures of MTBF for the product deliverable. Going outside the upper or lower control limit means the product is not compliant and the project cannot be on cost and schedule.

Connecting the dots between these measures

With the definitions of the above measure of Done—MOEs, MOPs, TPMs, and KPPs—let’s look at an example of how they’re all related to each other. Here’s a model that shows a working example of each of the measures of Done. Next we’re going to look at a project example.

getting things done
Figure 2 – The Measures of Effectiveness are derived from the Business or Mission need. Key Performance Parameters and Measurers of Performance describe how the project’s deliverable fulfill those Effectiveness goals. The Technical Performance Measures describes the engineering attributes of the product or services needed to enable the Performance and Effectiveness to be delivered.

Figure 2 – The Measures of Effectiveness are derived from the Business or Mission need. Key Performance Parameters and Measurers of Performance describe how the project’s deliverable fulfill those Effectiveness goals. The Technical Performance Measures describes the engineering attributes of the product or services needed to enable the Performance and Effectiveness to be delivered.

In this example, the Mission is to deploy a public service system. The local government is concerned about controlling disturbances, mitigating crime, and having forensic video and sound evidence for legal purposes

The county wants to procure a surveillance system with cameras and sound devices at strategic locations; send the data feeds via wireless technology, and monitor, store and retrieve selected incidents.

The government wants near real-time response and video quality that lets them distinguish facial features and read a license plates within 20 feet from the camera. They also want the system to alert operators when there’s evidence of a disturbance, and equipment that will store five years’ worth of data feeds collected 24/7.

The government submitted a Request for Proposal (RFP) to procure, install, test and train personnel. The government has set aside of budget of $40M and wants to system operational within 18 months.

How do we know when we’re Done with the project?

If you’re the project manager on this project, your immediate job is to develop a good Work Breakdown Structure (WBS), then determine the system’s Measure of Effectiveness (MOE). It’s also your responsibility to select appropriate Technical Performance Measures (TPM) and use these to inform or drive reported cost and schedule progress. Your next job is to be able to tell your customer (the government) that cost and schedule progress will be consistent with measured technical progress.

But that is far from sufficient for project success. Each Measure of Effectiveness, Measure of Performance, Technical Performance Measure, and Key Performance Parameter must be made as planned. That, along with the cost and schedule performance measures, risk reduction measures and any other meaningful measures used to inform the decision makers are part of the description of Done.

Figure 3 – MOE, MOP, and TPM for a public safety surveillance system to detect disturbances on neighborhoods using audio and video systems as well as emergency 911 dispatching. When these measures are met, the provided system if considered DONE.

what done looks like
Figure 3 – MOE, MOP, and TPM for a public safety surveillance system to detect disturbances on neighborhoods using audio and video systems as well as emergency 911 dispatching. When these measures are met, the provided system if considered DONE.

Conclusion

Cost and schedule compliance alone is necessary but not sufficient for project success. The product and the processes that produce the product must be compliant with the measures in Figure 2 for each critical deliverable.

Otherwise the resulting product or service will not meet the needs of the customer. And as a project manager, that’s what keeps you in business.

One great tool to get to Done successfully is using an estimation method that you can rely on. To learn more about refining your project estimate skills, download our eBook, “6 Best Practices for Accurate Project Estimates.”

Six best practices for project estimation

 

What Does Done Look Like? The Project Manager’s Dilemma was last modified: November 10th, 2015 by Glen B. Alleman