We've all heard this before, hire good people and let them learn from their mistakes.
The first question is who pays for people learning from their mistakes? Then the next question - with these mistakes, did the project advance in ways it would not have before we made the mistake?
And did the money we spent learning from our mistake "earn its value?" Or put in another way was there a better use of the money to advance our learning other than building something that we considered a mistake?
There are other questions as well. Why didn't we know this was going to be a mistake before we started? Or could we have known this before we discovered it failed? Or even better, was the failure we just experienced knowable at all?
This knowability question is the key to all project planning processes. If something is not knowable, then we could not have known, so we only discover our mistake after the fact. If it was knowable and we choose not to address it - ignore the potential problem - then we'll overrun our plan for no good reason other than we choose to ignore the knowable facts.
We may have a knowable issue, but can't afford to learn (pay money to learn), but that's different.
These questions and others need to be asked and answered before we can make any assessment if learning from our mistakes is a good idea. The alternative to learning from our mistakes is to do the job right the first time.
This of course is overstating the solution and somewhat silly, but it brings out a critical concept that must be addressed in any credible management process of spending other peoples money...
Who pays for the development team to discover their mistakes, if these mistakes could be avoided?
Once we have the answer to that question, we now have some decisions to make.
- Investigative work - discovery - is always needed on any development project. To think otherwise, means we have a production process.
- Learning what we need to learn needs a budget. In our domain this is the basis of the increasing maturity of the Integrated Master Plan paradigm. We move the project from left to right with increasing maturity of the deliverable. Budget is provided to discover what we need to know to meet the plan Measures of Effectiveness and Measures of Performance to comply with the Technical Performance Measures.
This is all fancy words for someone has to pay for us to learn what we don't currently know. And we need to make the cost of this learning visible as soon as possible if we're going to be good stweards of other peoples money.
So What's the Point?
The notion of Hiring smart people is pointless if they aren't allowed to make any mistakes ignores the managerial finance obligation to determine who pays for these mistakes, is the budget for making these mistakes in the baseline authorization, and if not, are we going to overrun our planned cost for the project and dilute the Return on Investment calculation that we sold to the owner of the project?
We seem to forget that writing software for money, means spending other peoples money for the expected amount of money (within the variance bounds) and showing up on or before some expected time (within the varaince bounds), with more or less the expected capabilities.
This is a Prime Directive (to borrow a phrase) for all projects. It's very doubtful the owner of the money says to us hey boys and girls, go out there and experiment around to figure out what will work and what won't work without actually budgeting for that experimenting work.
When there is explicit budget to experiment that's called explicit work for discovering what we dont' know, that is needed before we can proceed. We'd find that budgeted work in our plan for the project. No problem, all part of the normal project management process.
But the notion of Hiring smart people is pointless if they aren't allowed to make any mistakes needs to address Who, What, When, Where, Why, and How this discovery process is going to get paid for FIRST, then we can start failing on purpose to make the follow on work better.
