Performance Based Management

There was a question posed to me on Twitter from another post. The question was what should I read to learn about some of the things you talk about here?

Let's  go back to the top and start down the list. But let's start with some first principles.

Five Immutable Principles of Project Success

1. Do we know what the project is supposed to produce, the recognizable deliverables, the measures of success for those deliverables, and most importantly, the units of measure of the success that are agreed to by the decision makers?
2. Do we have a plan and a schedule to execute that plan? The plan tells us what we are supposed to be doing? The schedule tells us when we should be doing this work. Both a Plan and a Schedule are needed. But the Plan and NOT the Schedule and the Schedule is NOT the Plan. This a a fundamental failure mode for most projects outside the government program management domain. Look at the IMP/IMS Preparation and Use Guide for an overview of this paradigm.
3. Do we have enough resource to complete the project on time, on budget, and on specification? This means there must be a resource utilization plan. A resource loaded schedule is the best starting point. In many agile projects, there are fixed resources, so resource loading is simple. But in agile domains, rarely are there discussions of schedule margin, cost margin, or technical performance margin, so those approaches are swapping one set of problems for another.
4. Do we know the risks in the project and their Risk Handling responses? If not, the risks are still there and will turn into Issues and then you'll be late and over budget, and the outcome will probably not work.
5. Do we know that we are actually making progress? In agile projects working software is the tangible evidence to progress to plan. The plan being the series of stories to be produced. In traditional projects Earned Value is a good way to measure progress. In agile EV might be useful, but since the capacity for workis fixed, the outcomes  become the independent variable. Burn Down charts are used, but Burn Down Charts are NOT EV - useful but not a replacement for EV.

With these 5 Immutable Principles, we need a process to put them into a work process to actually increase the probability of success of our project.

5 Processes of Project Success

1. identify the capabilities that are needed by the stakeholders of this project. These are not the requirements, that comes next. A capabilities is an objective or the particular end state identified by Measures of Effectiveness (MoE) and Measures of Performance (MoP). These capabilities can be defined through scenarios from the customer point of view in units of measure of meaningful to the customer. The Concept of Operations (ConOps) is an example of defining capabilities. Capabilities answer the question what are we going to with the outcomes of the project to earn back the business value?
2. What are the technical and operational requirements needed to provide the capabilities for the stakeholders? This is where we map a requirement to a capability? This is a critical success factor of the project. This asks the question why do we need this feature? What capability is provided by this feature? How can business value be traced to the features that are being developed? This means each requirement is traceable to a needed capability. Each requirement is traceable to other requirements - usually in an N-squared matrix. The Design Structure Matrix (DSM).
3. Once we know what we need to do in terms of delivering capabilities to the stakeholders that they can put to work fulfilling their mission and vision, we need a Plan and a Schedule. By The Way - the notion that Earned Value is not interesting because it is not business value is of course nonsense. Earned Value is embedded in the Performance Measurement Baseline. Business Value is connected to the delivery of capabilities. These are mapped in the DSM. But both are needed.
4. With the Performance Measurement Baseline, the project participants need to execute the plan. This means taking each chunk of work and performing the defined activities. If this is an Agile project, these are stories. If it's a traditional project, it's Work Packages and their activities. The order of the work may be important or not. But the measure of performance must always be Physical Percent Complete. The details of how to do this take books, so this is just a simple overview.
5. In each of the previous 4 processes, Continuous Risk Management (CRM) must be applied. There are several paradigms for applying CRM. A good starting point is the Software Engineering Institutes, CRM. DoD has a paradigm as well. Pick something. DO NOT make this up.

Summary

I'll start a list of resources next. But for now this the framework for managing any project. By any I mean any, no matter the engineering development method. This means Scrum and similar methods, are just that Software Development Methods. They can be integrated with Project Management Methods, they can replace some project management processes.

In the mean time here's a collection of posts on Project Management Books.