Don’t focus on planning, focus on value
“An IT project is always late”: this phrase doesn’t make sense. As Gandalf wisely says it: “an IT project is not late nor early, it arrives precisely when it means to”.
TL ; DR :
I’m sure you’ve already heard this sarcastic phrase “IT projects are always late”. It doesn’t make sense for two main reasons:
- First, an IT project is highly unpredictible. It goes back to the combined complexity of computer systems and users needs. Therefore, it’s impossible to anticipate a priori everything that could happen during an IT project. Hence, speaking of “delays” doesn’t make sense : how can we be late if we’re not able to anticipate the duration of something in the first hand ?
- Second, planning is the last thing you want to focus on when developing an application. Shipping features within the expected timeframe but without bringing value to your end users is useless. Focus on the value delivered. That’s the only thing that matters.
- Finally, if you’re absolutely required to give planning estimations, do it wisely. Perform estimation of small batches of work which will be more accurate. Actualize a lot these estimations. And most importantly: communicate with a lot of caution about these timing issues for the reasons mentioned above.
When it comes to IT, the notion of “being late” / “delay” doesn’t apply
An IT product / project makes you deal with two complexities: (1) computer’s complexity and (2) users’ needs complexity. This makes it impossible to define or measure rigorously any delays.
Computer’s complexity: an IT project being late would mean you can anticipate all the implementation caveats before even starting it
Let’s picture ourselves a quite classic story to illustrate this point.
- You’ve planned on shipping a feature at the end of week 1
- Once you start building the feature, you realize that you need first to perform a major upgrade of a technical brick.
- The feature you’re developing depends on this upgrade, and without it, you won’t finish it
- You need one week to perform the upgrade and you will only be able to ship the feature before the end of week 2
Is it a delay?
- We were not able to identify the need of the upgrade in the first place, the scope of what had to be done changed after this identification.
- If it had been identified before, it would be correct to say that we were “late”. As it had not, it cannot be said that it was a delay.
- One might argue that we should have been able to identify anything from the start but that’s just impossible as we’ll explain it afterwards.
- Thus, NO, it’s not safe to say that the feature was delayed in this context.
This kind of issue actually goes back to the complexity of computer systems that consists in two main aspects.
First “intrinsic complexity”: an IT system is composed of several different components. (A) The behavior of the whole system cannot be reduced to the sum of the behavior of all its components. This makes quite harder the identification of causal links in the system. And therefore, (B) the same action performed at two different moments doesn’t imply the same results.
As a consequence, you will never be able to anticipate everything without a holistic view (A) and even if you can anticipate some things, the behavior of components might not be the same over time (B).
Second “interdependency complexity”, an IT system never lives in isolation. Softwares rely on other systems, libraries, APIs. Softwares are in the end deployed on servers that are composed of hardware devices, fueled by electricity and so on. You are not alone whenever you develop software and you cannot secure and cross-check that all the “partners” you rely upon won’t block you.
As a consequence, issues will happen and they will make your job harder; you cannot control everything, especially when it comes to external partners. That’s a fact and you have to deal with it.
Users needs’ complexity: you cannot forecast all the users needs regarding a tool without showing it to them. You cannot do it by anticipation
Another anecdote to illustrate this point:
- Back to the early days of Google, they conducted user interviews to identify if people would rather have a long list of results whenever they were searching for something.
- 10 ? 20 ? 30 ? The users told they wanted to have “as much results as possible”.
- When Google implemented it, they realized that their users weren’t happy: the higher number of results induced a slower response speed. In the end, users would rather have less results but a quicker response speed.
- They wouldn’t have been able to identify this without showing the working website to the users.
This time, once again, we cannot say that a feature is delayed just because it wasn’t shipped within the expected timeframe because of a misunderstood user need. It’s just impossible to anticipate the user experience before you have a tool.
Just like computers, humans are complex and you cannot anticipate all the functionalities that they would have in a given tool without showing them prototypes or a beta version of the application. With all the user research in the world, you won’t be able to fully anticipate these needs. Hence, it doesn’t make sense to expect a software “not to be delayed”: the timeframe will be continuously adjusted to emerging user needs.
What’s next then ? If planning is not the right thing to measure, how can we handle efficiently IT projects ?
Monitor the value delivered by a tool and not the fact it’s been developed in the expected timeframe
Focus on the right thing: value delivered to the user.
- Go talk to your users and ask him bluntly if the software you’re giving him access to is useful for him. You can do that during demonstrations or schedule ad hoc meetings. How you do it doesn’t matter as long as you do it. For instance, Reed Hastings Netflix’s CEO has a customer-testing session every three months.
- Do not only focus on what the user says, use analytic tools, observe the behavior in order not to biase this analysis. Remember that as the Google users mentioned above, users are often wrong about what they need. I’ve deep dived more on the topic in this article about MRI for kids.
- Prioritize your work accordingly. The only reason why a given feature is on the roadmap should be that it delights our user. Period. It should not be because the CEO or a sponsor likes it. It should not be because it’s a feature we’ve put on our roadmap for a long time.
If you still need to provide visibility on planning, be very careful with estimations and communication
Sometimes, your sponsors will be very pushy and agressive about plannings and deadlines. Thus, you might have to give them “timing estimations” and answer to questions like “are we late ?”.
- Small batches of work are key in order to give more predictable estimations. By developing software incrementally and trying to have a software always releasable, many things will be easier and more predictable. For instance, all we said about interdependencies remain true. But by being more incremental, you will identify dependency incrementally and deal with them one by one without having the complexity of dealing with their combined impact.
- You can also estimate higher volume of work. But when doing so, try to do it by using references to past projects : “the amount of work to perform broadly corresponds to half of this other project we’ve finished a few months ago”. And use some margin.
- Actualize a lot your estimations. Planning should always refer to the process of thinking about estimates and not about the “plan” in itself. As most of your initial estimations will be false, make sure you go back to them quite often. Scrum advocates planning adjustments at every two week-sprints which is a good rule of thumb.
- Most importantly: communicate with a lot of caution about a given project / product being developed on schedule or not. It doesn’t mean that you should always be pessimistic and put an extra margin of 200% on any roadmap you’re presenting. But be very transparent about the fact that any estimation about an IT task is most of the time not reliable on the long run. More ambitiously, you should also advocate the right ways to think about IT : your sponsors are able to understand that roadmaps and timeframes shouldn’t be our primary focus.
Tired about people being focused on IT products / projects being late or on track ? Join us:
Interested about tech like us? Get in touch with us and stay tuned for more articles to come.
