Three Rules to Create Better Tech, Faster
A McKinsey study made headlines a few years back with the statistic that 70% of digital transformation projects fail. When I look at how we’ve been able to consistently beat those odds, the most critical factor has been timelines.
To successfully use deadlines to drive transformation, you need to follow three rules:
There must be a respected deadline.
The deadline must force decisions but not drive them.
The deadline must have either room for error or room to move, but not both.
There must be a respected deadline
Any project without a deadline is at high risk of never completing. This may surprise some people: an open-ended project sounds like it would be great. Let it take the time it needs to take.
The problem is that a top killer of tech projects is failure to make decisions. That’s right—not bad decisions, the absence of decisions.
Many choices in the implementation phase aren’t easy to make. They involve trade-offs and competing interests. They’re not appealing to wade into. They may involve disappointing people or resetting expectations. When there’s no deadline, there’s no particular motivation to take on these unpleasant choices. And so, they tend to linger—repeatedly discussed, but never resolved.
Why is this toxic to your tech project? Every day you don’t make a decision is a day a particular task can’t move forward. That task is likely connected to other tasks and decisions. Eventually, a lack of decisions means either nothing can move forward or, more likely—since management is usually demanding progress—people make their best effort to move forward without clarity. This inevitably leads to wasted effort and rework.
This is why most outside consultants require sign-off on scopes and key decisions before proceeding. Internal teams would be wise to implement the same. (We do in our company: we scope, quote, and require sign-off on internal projects just like we would a client project.)
When those decisions are delayed, the overall project suffers, and the team’s momentum suffers as well. It’s hard for people to stay motivated when they’re being told something is very important, but their managers aren’t giving them what they need to succeed.
The deadline must force decisions but not drive them
The existence of a deadline that’s adequate but not overly relaxed means leaders are forced to make decisions—and this is overall a good thing for the project. But is a more aggressive deadline better?
In a word, no.
The timeline is the silent gatekeeper of an app project. It creates a constraint against which all subsequent decisions are measured. This is especially true in highly regulated industries, where there are firm protections against cutting corners in security and compliance.
Sometimes leaders turn to an aggressive deadline in an attempt to create momentum. They may be impatient to get to launch or show the board what they can do. It may also be a bit of grandiosity, as it would make them feel powerful and special to be able to accomplish a deadline most would say was unrealistic.
While the ego wins, the project suffers.
Every project has unexpected choices that arise: things go wrong, opportunities spontaneously appear, and business keeps right on shifting while the project is in motion. All of these choices will be compared against the deadline. And if there’s no margin, the opportunities get cast aside, and the unexpected hurdles can become roadblocks.
As much as part of you wants to be able to say you launched the impossible project in six months, this is not a positive outcome.
I mentioned earlier that this is even more true in highly regulated industries. This is because a portion of the roadmap is filled with musts. You must conduct a penetration test. You must handle library upgrades. You must ensure compliance with HIPAA. You must implement log monitoring.
This shrinks your margin for handling unexpected risks and opportunities even further. At some point, an excessively tight deadline will cause leaders to make decisions that are bad for the project overall, but are necessary to meet the deadline to which the team has already committed. You don’t want to be in a position where the project outcome is being sacrificed for the deadline.
The deadline must have either room for error or room to move, but not both
The most effective deadlines bend but don’t break. You can accomplish this in a couple of ways: you can build in extra time to handle contingencies from the start, or you can give yourself a pressure relief valve—a secret second deadline to which you will extend only if required.
The advantage of giving a singular deadline a realistic buffer—but not moving it—is that you provide a reliable, consistent message to the team. If the deadline is January 1, it remains January 1. It also shows the team that the project has been planned well from the start, as they can see that contingencies have been accounted for. This builds confidence.
The disadvantage is that there are some human behavioral characteristics that come into play. Without a disciplined process, a deadline that feels generous has almost the same effect as not having a deadline (perhaps even a stronger one) because people feel they have all the time in the world. There comes a point in every luxuriant timeline, however, where the end is nigh and suddenly the team (including the leaders) must face all of the things that have been put off for later. These inevitably outstrip the available time, and choices must be made. Nonetheless, this can be successful as long as you have a strong project management process.
As mentioned, there is another option: provide a less ample timeline that’s still realistic—but just barely—with a reserved contingency window that only comes into play if needed. The challenge with this approach is deciding what constitutes a reason to invoke the extra time. I’ve yet to see a project where the team would not have welcomed another week or two if offered, so it can become a foregone conclusion or a reason to not take the original deadline seriously.
It’s also worth considering how the extra time is used. Extra time can be used well, or it can lead to ill-advised late-stage revisions that won’t be adequately tested before release. Our policy is to think about the testing requirements and ramifications of various improvements, and only leave low-risk, easily tested items for the end.
The less obvious challenge of this method is that you have to decide how widely communicated the pressure release valve is. If you broadcast it to the entire team immediately, there’s a nice transparency to it—but you may find people expect that it’s a given if they want it. That can lead to poor decision-making, such as doing things in a rushed way, assuming there will be an opportunity to revise later. This creates the aforementioned testing challenges if things are being refactored extensively at the end, and may even invalidate security mechanisms such as a penetration test.
Given the choice, six times out of ten I’d pick a fixed deadline with adequate time built in over a secret lever to buy a few more weeks. It’s more clear to everyone involved. There are nuanced situations, however, where the pressure relief valve makes more sense.
Regardless of the method chosen, do not allow for both. That gives a timeline too much uncertainty, and it starts to lose its impact.
Why every deadline needs a Day 2 list
One paradox of development is that the closer you draw to release, the more great ideas will tumble out of you and your team. It’s a natural result of the excitement that arises when team members can actually see it working.
While there are a few people who can visualize an app’s impact from sketches and flow diagrams, a great many are inspired by holding the genuine article in their hands—or seeing it on their monitor, miraculously working. That little moment of joy and wonder has sparked a great many brainstorms.
So what to do?
You have a timeline. There are three weeks left. And definitely no time to implement this fantastic idea you or another team member has just had. Unfortunately, now that the idea is in the ether, you can’t unsee it. Anything less seems underwhelming.
When you feel that frustration creeping in, pause. First, recognize that these sorts of feelings are normal and your mind may well be playing tricks on you. Next, take the brilliant idea and move it to the Day 2 list. That’s right, the show must go on. Everything that’s in your current batch was something you were once excited about and couldn’t wait to get out the door. It has value. The problem is, your mind has already made it real and moved on to the next thing. Reel it back and be present in this moment. You – and your team – have earned it.
And remember, the timeline can help your project or doom it. Clarity drives success.