My two previous posts, looking at the reasons for deviance between management and engineer views of projects, attracted a number of comments, primarily in two camps. One camp spoke of Management-in-Denial, going into the reasons and contexts why an enterprise would behave that way, travelling into shareholder-versus-customer expectations along the way. A second camp looked orthogonally at the same shareholder-versus-customer contention, suggesting that the expectations diverged right at the start, and that we need to get better at reducing that initial divergence by concentrating on pragmatic realities. The arguments then morphed into a classic marketing-versus-engineering debate, what we used to call vapourware or markitecture or, more recently, software-by-powerpoint.
It is hard to summarise a series of comments, you can’t edit snowballs. My apologies to any and all who feel I’ve misrepresented the arguments. If you want to know what they really said, read the comments.
I get the feeling that both camps concentrate on what happens after fan and excrement are in simultaneous play, rather than in the prevention of said occurrence.
I’ve had to manage projects in some form or shape for a couple of decades now, and so far nobody in management has ever asked me to lie, even if I’ve been that “management”. Sometimes I’ve been unhappy with the techniques used to present “reality”. Sometimes I’ve been unhappy with late changes to schedules and deliveries presented to me as a fait accompli. And sometimes we’ve just got it wrong. But it hasn’t been about lying or being in denial.
How can we get better? Here are some personal musings:
1. Let the deadline influence the design
When you ask someone to do something, one of the design criteria, an important one, is time. Once you agree on time, you can negotiate the functionality and performance characteristics of the deliverable. Often you have to negotiate with a set of “incomplete contracts” but that’s life. Emotion can be taken out of the negotiating process; agile techniques can be used to learn more about detail aspects of functions and performance; there is a continuous improvement process explicit in all this, and sometimes it results in a continuous migration process, when you have yesterday, today and tomorrow systems in parallel. Time-boxing and time-placing techniques are based on this, yet for some reason get little airplay.
How come everyone got ready for things like EMU and Year 2000 and Sarbanes-Oxley and all that jazz? Because there were two projects in each case. One did the paperwork. One did the real work. The ones that did the real work knew that the dates couldn’t change, so they negotiated on the What and the How rather than the By When. Which brings me to my second point.
2. Get the signal-to-noise ratio right
More than once, I’ve been involved in projects where the governance mechanism is larger than the project team, and where the pressure placed by such mechanisms creates more paperwork than code. This does not create a divergence between management and engineer; it’s fairer to say there are two projects, one producing paper and one producing code. And sometimes there is only one team having to do both, with predictable results.
As long as we have an Armaggedon approaching for the battle between professions, and as long as organisations haven’t completed their painful trip from hierarchy to network, we’re going to have intermediaries. And there is a price to pay for having them. The only solutions I can see are twofold: One, try and make the doer-to-checker ratio an integral part of the reporting pack, so that the cost becomes visible. Two, use the remaining checkers wisely, they can help in many ways. Which brings me to my third point.
3. Pass ownership to the real customer as soon as possible
We use terms like fast iteration, early testing, agile development, fail-fast, whatever. Hitherto I’d been worried about the tension between such approaches and the classical waterfall or cascade approaches. But the more I think about it, the more I feel that the approach-conflict is but a symptom. The root cause is a blame culture. Which sadly pervades too many organisations. So what we need to do is to find ways of reducing the impact of this blame culture. As far as I can make out, the best (perhaps the only) solution is to place something that works in the hands of the real customer, that can be used to create or derive value. Once you do that, all the dynamics change. Even if the value is marginal to begin with. Which brings me to my final point.
4. Get legacy skin into the game as soon as possible
Don’t talk parallel run. Don’t talk big bang switchover. Carry a big stick, move low-volatility information from Old to New as soon as humanly possible. Expose what you’ve done to the customer, and soon the old will atrophy and the new will thrive. [Note: There is an exception to this, an important one. Sometimes you get involved in building systems that are expected to do precisely what the ones they are meant to replace do in the first place. To the letter. No point getting legacy skin into this game, the customer doesn’t want the system. Get out quick.]