Why is it So Hard to Plan Well Up Front? – Part 2
Posted by Brad Egeland
In Part 1 we looked at the problem with up front planning and requirements definition and the first of three key American cultural tendencies that can contribute to this problem … impatience with time.
In this Part 2, we’ll look at two more cultural issues – the acceptance of mistakes and the urge to improvise.
Acceptance of Mistakes
America has often been called the land of comeback opportunities. Everyone gets a second, third, fourth, fifth chance and so on chance. In the US, we tend to forget the trials and tribulations of the process and focus only on the end result, saying “Because it worked out okay, there’s nothing to learn.” In fact, we admire comebacks more than people who never failed in the first place. We honor them. We are more loyal to a supplier who quickly fixes a mistake he makes than we are to a supplier who never makes a mistake.
Most people in project and product development assume that mistakes are inevitable. Some mistakes are. However, we often confuse preventable mistakes with inevitable ones. Poor preparation and inadequate understanding of customer requirements result in what I’m referring to as preventable mistakes. There’s really no honor in scrambling at the last minute and running over budget to get out a solution to a customer when it could have been prevented up front with better planning.
Urge to Improvise
It is in our culture to improvise. Often, we become heroes by improvising. We tamed most of the continent with what we could carry on our backs. We brought Apollo 13 back safely from its disaster-stricken voyage to the moon with duct tape and ingenuity. McGyver was a TV hit. Some of our biggest heroes are improvisers.
Combine our easy acceptance of mistakes with our love of the challenge of solving the unsolvable on the spot with whatever we have available and you have a recipe to maximize rework.
I have worked along side project managers and developers who believed that solving the unanticipated problems under the gun was the fun part of the project. These people often resisted requirements definition because they believed it reduced the need to improvise and took funds away from what their experience told them they would need it for later … that’s right … rework.
Summary
We have a natural bias toward making assumptions. People often don’t ask critical questions because they think they’re supposed to know the answer already – or they may incorrectly think they know the answer and don’t bother to verify. Our reluctance to reveal ignorance often starts during formal education and studies have shown that it is actually more prevalent in men than in women. Men often feel a greater pressure to remain silent and not ask the difficult questions.
When examining positional relationships, studies have shown that technical professionals are much less likely to ask questions in business training classes than their non-technical counterparts. You can see how problems surrounding assumptions and interpretations can be quickly compounded in this type of thought process.
The silence of your project team is not always due to posturing. On project teams, people tend to assume that someone else knows when things are going wrong. The lessons learned to take away from this goes beyond just the need to plan for good requirements. It also involves the need to ask questions, avoid making assumptions, and avoid basing action on your own interpretations and understandings.
Related posts:
Post comment
