Okay, buckle your seatbelt for this one. It’s a simple idea that is essential for healthy design, innovation and producing high quality work, but it’s pretty counter-intuitive for most IT pros. Let’s start with the first part: “Start work as soon as possible,” or
How often have you heard, or maybe asked, this question, “When will the requirements be done and locked?” Or, “When will the research be finished?” Or, “When will spec be signed off?”
Most people like to ask these “When will the work be done” questions because we feel like the answer gives us a measure of progress. We know that when a certain category of work is complete, it adds to the road in our rear view mirror and less road remains ahead.
Too often, however, we find that the work we thought was complete still has errors and must be revisited. Only when we start writing specs to we realize that the requirements are ambiguous. And deep in the code, the developers complain about the clarity or feasibility of the specs. And in production, business users realize that the product isn’t having the impact they had hoped. It’s easy to blame these errors for the roughly 60% of all IT projects that fail.
So next time, we figure, we’ll take more time and care. We’ll do a better job with requirements before we hand the work off to the team responsible for the next step. We implement inspections, stronger governance and quality reviews. But next time, we find the project takes longer, we’ve still made mistakes and our odds of success not only haven’t improved, they seem to have gotten worse. WTF?
Turns out that the key to higher quality lies in starting design before requirements are locked, in starting to code before the specs are done, and testing as early as possible. In other words, starting a later stage of work before the earlier stage is finished will quickly surface problems with the previous step.
Here’s why. Designers and the best ones to judge the quality of requirements. Developers are the best ones to judge the quality of specs. Users are in the best position to judge whether the code we ship is useful or not. Trying to ship quality artifacts without involving the consumers of that work is super difficult and time consuming. A more effective approach is to develop the artifacts collaboratively with the people who depend on them by inviting them to use them before they are complete. Leave time to revise the work as you go. You’ll find that the total time to produce top quality work goes down. And you’ll waste less time working on stuff that doesn’t add value further on down the road.
Starting work as soon as possible, without waiting for the prior step to be complete, actually takes less time and effort and yields higher quality results. But, here’s the rub. Asking when a category of work will be complete shifts the team’s focus to completing that work and discourages them from starting the next step as soon as they should.
Better questions to ask are, “When will the first design session happen?” or, “When will the first prototype be testable with users?” These questions encourage the team to work together and communicate that it is okay to take a more pragmatic approach to quality.
Okay, let’s move on.
Most of us have a natural aversion to ambiguity and uncertainty. Making decisions feels good. We sleep better knowing that there are less moving parts in the system and that future decisions will be simpler because of it. And when the cost of not making a decision clearly stares us down, by all means, we should make it.
On the other hand, delaying a decision leaves us with more options. And as the project progresses, we may find that some of those options have unexpected value that we couldn’t have anticipated earlier.
Of course, it’s easy to imagine situations where deciding late would be catastrophic. In those cases, of course, decide earlier. Use your best judgment. All we are saying is that you should consider the relative tradeoffs of when to make a decision and be intentional about it, that’s all.
Developing a bias for starting work and delaying decisions can be magical because it accelerates insight, reduces risks and encourages more effective and informed decisions. Try it out and let us know what you think.