Have you ever been a part of this weird - yet very common - dynamic? The successful disaster?
You are on a project that is an utter disaster. By fight and by fire, months late, and millions (thousands) of dollars over budget your team finally ships the product, and then everyone declares it a "SUCCESS." From the CEO to the developers, they even throw a launch party.
I've been a part of a number of these. There is genuine success from shipping anything. As Alan Cooper and Fred Brooks point out, there is far less wrong with shipping late than people think. Most projects meet a business need, even when they ship late.
I'm not talking about value in this post. Business value can be measured using analytics, or interviewing the business people after they used the product. This post is about the development process from the first engagement to shipping the product.
I'm talking about the design and construction process itself. I'm talking about the things we do - the developers, the PMs, the Managers - the software project people. It was our plan that was way off. It was our budget that was way over. It was our feature-set that was allowed creep. Why are we celebrating the launch as a success? Why are we glad-handing and back-slapping? Our business is process-management, design, and construction of the software. What have we got to be proud of?
For us, it's not enough that the product shipped. It needed to ship when we said it would and cost what we projected it to cost. We didn't do our job. We promised the business they could have the results of our project in X days and for Y dollars. If X and Y are different then we promised then that represents a different project - not the one we promised. Something is seriously wrong. Once X and Y change, any value is at best accidental. It's certainly not do to our skill and planning. Instead of celebrating a success, we should be exploring where we went off track. The near-miss is important to notice and to use to learn.
There is some psychological evidence as to why is this failures-are-really-successes happens. This excerpt from Simply Psychology explains the state of cognitive-dissonance. Think of your last challenged project when you read the last paragraph:
Leon Festinger (1957) proposed cognitive dissonance theory, which states that a powerful motive to maintain cognitive consistency can give rise to irrational and sometimes maladaptive behavior.
According to Festinger, we hold many cognitions about the world and ourselves; when they clash, a discrepancy is evoked, resulting in a state of tension known as cognitive dissonance. As the experience of dissonance is unpleasant, we are motivated to reduce or eliminate it, and achieve consonance (i.e. agreement).
Cognitive dissonance was first investigated by Leon Festinger, arising out of a participant observation study of a cult which believed that the earth was going to be destroyed by a flood, and what happened to its members — particularly the really committed ones who had given up their homes and jobs to work for the cult — when the flood did not happen.
While fringe members were more inclined to recognize that they had made fools of themselves and to "put it down to experience", committed members were more likely to re-interpret the evidence to show that they were right all along (the earth was not destroyed because of the faithfulness of the cult members).
----
So just to be clear, the MORE people have at stake in a project, the more committed they are (working nights and weekends, always available), the MORE they must declare it a victory/success when it was clearly an utter disaster.
This makes the phenomenon of the declared success almost a certainty. The architect has their career on the line, the president/CEO can't be CEO of a shit-show, the project manager can't have led a chaos carousel, and gee, didn't all the developers "learn a lot during this project?" The declared success, kills the near-win.
The "near-win" so eloquently described by Sarah Lewis in this TED Talk is dangerously undermined by the "declared success." If we do not recognize the disaster, we will not recognize the near-win and we will lose our edge for mastery:
Moving forward I want to get better at every project. This cognitive-dissonance makes learning very hard because you've declared the project a success - and we want to repeat successes. Learning is about being critical. Learning is about feedback loops that say, this time around we are going to try this based upon what we didn't like the last time. If you can't point out that the emperor is naked, it's hard to create a quality wardrobe.
The question was raised, "Isn't shipping of any kind a success?" I do address that in the article, but there's a bit more too it...
ReplyDeleteIt is arguably a success for the business, which should be objectively measured with analytics and business drivers.
But for the design and construction crew, the challenge is different.
Suppose I tell you a project can be built for $10 and you say, "great, I know it's worth at least $1000 to the business, let's do it." But then I get halfway done and say, "You know, I was wrong, it's going to take a $1,000,000 to build it." I'm guessing that once this is understood, cancellation can now be viewed as a success and the time and money spent is water under the bridge.
What we want is the ability to predict early, the cost, effort, and schedule of producing software so that the business people can tell us if it's worth it to them for us to proceed. Then, once we begin we want to be able to keep our word because this very process means that success should be measured along the cost/time curve.
It's a very different proposal to go before a business and say, "You can have this for $100,000 in 3 months" and "You can this for $1,000,000 and two years." We (the design/construction crew) should present these options. The business should tell us if it's worth it.
The problem with the "declared success" is that it makes legal liars out of everyone. The legend of the project becomes skewed. The people involved drift away leaving the fools behind, free to fail again, only to declare success once more.
This mentality leads to the situation that, for every team you join, you must ask yourself - "Are these the fools left behind that think their failures are greatness?" or "Is this a team that has learned from it's mistakes and the next project will be the best they have ever done?"
It's very hard to tell when surrounded by so much false success.