Plans are nothing, Planning is Everything
The notion that plans are nothing but planning is everything is a common mis-applied quote. The clip art and content extracted from the current edition of Defense Acquisition Journal, November-December, 2013.
The ever-quotable Dwight D. Eisenhower, speaking to a group of industry executives who could be mobilized for war at a moment’s notice, was echoing an old adage about warfare: “No battle plan survives first contact with the enemy.”
Eisenhower’s message, like the man himself, was straightforward: “The reason it is so important to plan [is] to keep yourselves steeped in the character of the problem that you may one day be called upon to solve—or to help to solve.” He was reminding them that warfare is inherently fluid, and that the only way to adjust to quickly changing circumstances is to have planned for such contingencies in advance.
For our project management domain, Plans are considered Strategies for the successful delievry of the project's capabilities. But this strategy is actually a hypothesis and this needs continual testing. The best way of course if testing the hypothesis is working product at periodic points in the project. Some would say this test should be every few weeks. This of course - as always - is domain dependent. But at a minimum every month.
In our Earned Value Management domain, the monthly Contract Performance Report (CPR), requires an assessment of physical percent complete to calculate the BCWP (Budgeted Cost of Work Performed). The planned cost of producing this value is BCWS (Budgeted Cost of Work Scheduled).
BCWP = BCWS x Physical Percent Complete
On the planned day for the planned cost. Don't show up on the planned day for the planned cost and the planned physical percent complete? You can't be on schedule and on budget.
Now Add Technical Performance Measures and Quantified Backup Data
The determination of Physical Percent Complete starts with Quantifiable Backup Data. Percent complete is never a guess or an opinion. Tangible evidence is needed. But tangible evidence against the planned percent complete, on the day we planned to be that percent complete. This is nearly identical to Agile's approach to delivering working software at the end of an iteration. Not quite, since agile allows you to drop planned deliverables without an penalty to the current performance measure. This mortgaging the future by pushing undelivered features into the future would not be counted as complete in Earned Value.
