What Does Done Look Like?

To answer the question, we need more than cost, schedule, and requirements. We require a set of capabilities that are agreed upon, and tangible evidence that they have been delivered. In Part 2 of a series, we show how to go about discovering the capabilities required for project success.

In the first installment of this series — “5 Questions PMs Must Ask ” — we outlined the five immutable principles that must be addressed by project leaders and teams in order to succeed. They take the form of questions, and in this article, we will answer the first question: What Does Done Look Like?

The Project Management Institute suggests we start exploring the question by defining the requirements of the project. The AACEI Total Cost Management guidance agrees, as do any number of other project management methods. But this is wrong.

Requirements require a reason to exist. That reason is the answer to the question “Why?” — why are we doing the project? Why is the customer willing to spend money to have work performed?

If we don’t have an answer, it is difficult, if not impossible, to assign a value to any of the requirements, technical or operational. To meaningfully answer the question “Why” we must develop a set of needed capabilities —defined simply as the capacity to be used. But that’s a bit too simple. An IT-related definition from The Open Group Architectural Framework says the capacity of being used needs to be applied to a project and the products it produces. This gets us to capability planning — we need to plan the needed capabilities of the system before we can know why we are implementing specific requirements.

Capability-based planning has long been entrenched in the Defense domain in the U.S., U.K., Australia, and Canada. The associated governance mechanisms, as well as rigorous capability derivation, emerged from the systems engineering domain. So what’s the definition of capability planning?

Capability-based planning focuses on the planning, engineering, and delivery of strategic business capabilities to the enterprise. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability. Capability-based planning accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond (e.g., an emergency preparedness unit) is required and the same resources are involved in multiple capabilities. Often the needs for these capabilities are discovered and refined using business scenarios.

Here's a diagram for discovering the Capabilities needed for the success of the project

Capability-based planning starts identifying customer needs in terms of scenarios rather than requirements. This answers the questions Why do I want this, and What am I going to do with it when I get it? The document representing the capabilities is a Concept of Operations containing the scenarios that implement the needed capabilities. Only then can the requirements be derived. Only then can each requirement have a reason for being present.

Once we have the Capabilities, their Measures of Effectiveness and Performance, the Key Performance Parameters, and Critical Success Factors, we need to identify the technical and operational requirements, plan and schedule the work to deliver those capabilities at the needed time for the needed cost.

With the plan in place, a Schedule is needed to define the work and the sequence of that work to produce the deliverables. But this schedule must define what done looks like first, before defining the work efforts to get there. This approach starts with defining the maturity assessment points in the project where we ask and answer the question: What level of maturity for each deliverable is needed at this point in the project to continue to make progress as planned?

The diagram below shows the process of vertically scheduling the project for each Program Event — through Work Packages to their Accomplishment Criteria, to the Significant Accomplishments, to the Program Event. Only then, can planning take place horizontally for the dependencies between Program Events or Milestones.

These Events or Milestones are assessments of the planned maturity of the products or services. They are maturity assessments, where pre-defined deliverables are assessed to ensure that Technical Performance — measures of what done looks like — is being met against the pre-defined metrics. In addition, it ensures that the pre-defined levels of risk are being retired or mitigated as planned.

This approach to defining the master schedule is a paradigm change from traditional techniques. This change starts by measuring progress as the completion of Accomplishment Criteria and the fulfillment of Significant Accomplishments. This progress is described as physical percent complete rather than measuring progress through the passage of time and consumption of resources. The elements of this approach include:

Events or Milestones:

• Project-unique, key transition points between major program activities.
• Points of convergence across the entire program where specific functionality comes together for release, testing, or integration.
• Key decision points where it is necessary to assess progress in achieving objectives before proceeding.
• May include major milestone reviews, program design reviews, tests, deliveries, and other key progress demonstration or risk mitigation points.
• Should be well distributed over the program/project period, and not inordinately clustered. It is not desirable to have too long a period pass without checking critical program progress.

Accomplishments:

• For each Event or Milestone, the project shall state what progress is to be measured at the event.?This breakdown of principal tasks and activities becomes the accomplishments.
• An accomplishment is the desired result(s) prior to or at the completion of an event or milestone that indicates a level of the program's progress.
• The Accomplishments are critical efforts that must be completed prior to completing an Event or Milestone.

Criteria:

• Are measurable and useful indicators demonstrating the required level of maturity and or progress has been achieved?
• Criteria include using Technical Performance Measures and other metrics wherever possible to provide measurable criteria. Preferably, the accomplishment criteria should avoid the use of percent completed and avoid citing data item report numbers rather than identifying and summarizing results.