Do It Right or Do It Twice

I heard this phrase in a conference call yesterday with a DOD client and thought, how clever I'll write a blog about this. Only to find out there is a Forbes article with same name and several other articles as well. 

The Forbes article had a case study about doing it right around a business process. It was the perfect framework (repeated here) for applying Performance-Based Project Management^® 

In the Forbes article there are five steps:

1. The Vision Meeting - develop a set of needed capabilities for the outcome of the project. These provide the ability for the business to do something of value. There is all this discussion around creating value, but rarely are the units of measure for value mentioned.
• Value cannot exist if we don't know both the units of measure of the value itself and the cost to deliver those units of measure. This is where the naive and ill informed notion of #NoEstimates and the phrase we are exploring for ways to make decisions with "No Estimates" goes right in the ditch.
• The analysis of alternatives is a starting point. Balanced Scorecard is a broader approach, but AoA will work for this post. If we have some idea about what capabilities we need to possess, then we can make decisions about them. What do they cost? How do they actually provide value to our business or mission.
• What are the units of measure of that value. One good unit of measures is effectiveness. How effective will this new capability be in solving our problem?
2. Build a strategy - what is the Plan to deliver the needed capabilities. The notion that we don't need to plan - we'll let the resulting capabilities and their technical and operational requirements emerge - is of course going to allow us to Do It Twice.
• We need to know what DONE looks like in units of measure meaningful to the decision makers. The Plan is not the schedule. The Plan describes what will be delivered.
• The schedule shows when it is needed to deliver the value. We need both. 
3. Adapt if necessary - the needed capabilities should pretty much be fixed. If not we're wasting time and money exploring for what DONE looks like.
• That's called Research. No problem, if we acknowledge we are on a research project. If the customer thinks - and has paid us - we're on a development and delivery project, there's going to be disappointment when we discover we've spent a bunch of money exploring when we should have been delivering.
• When I here about projects where the customer doesn't know what they want yet, so let's get started and we'll discover along the way. Go back to the office and get a bigger check book.
4. Execute in time boxes - time boxing, rolling waves, incremental, iterative execution and delivery are  common sense. No one knows enough about anything at the detail level to know how to build it far into the future.
• The Capabilities shouldn't be changing, but the mechanism for delivering these capabilities must be flexible and adaptable. The key outcome from executing in time boxes, is the answer to the question - how long are you willing to wait before you find out you are late? The answer must be, short enough to take corrective action to NOT be late. This time interval is domain and project dependent. But answering this question will define your business rhythm.
5. What are we working on now? What are we working on next? - make this visible. Have a plan of the month, a plan of the week, a plan for this quarter.
• Have everyone on the project acknowledge they know what the outcomes of this plan are in units of performance, technical performance measures, and the quantifiable backup data showing physical percent complete.
• We must measure progress in this manner. This is the notion in agile software of working software. But the agile community doesn't have a formal way of stating the units of measure of working. They leave that up to the customer, who may not know. The Systems Engineering paradigm does, through Measures of Effectiveness, Measures of Performance, and Technical Performance Measures.
• Create a framework based on these, and only then insert your favorite agile development processes.

In the end project success is about knowing what done looks like, knowing how to get there, how to measure progress along the way. And of course knowing impediments to progress and handling them. These concepts are instantiated in two papers from a colleague Pat Barker, What is Your Estimate at Complete and Program Master Scehdule Can Improve Results, on page 20.