In the Army, we had this saying: be at the right place, at the right time, in the right uniform. We also learn to do extensive risk mitigation. I’ve taken a lot of this to heart to learn that in the worst case, you end up in the wrong place at the right time, or the right place at the wrong time. With a bit of mitigation, you can get it to wrong place, before the right time; or, right place, before the right time.
This extends to project management: wrong place means building the wrong project, or wrong time means late. When starting a project, mitigating these things is simple to say, but hard to implement.
The Wrong Project
It’s remarkably easy to do this. I’ve seen it done a hundred different ways. Hell, I’ve even participated. If you build something that doesn’t have a good market fit, you probably have built the wrong project. If you find yourself with a project that’s hard to market, you’ve probably got some scope creep … and you’ve built the wrong project.
Mitigating this is deceptively simple: research. On the face of it, doing research for a product that doesn’t exist should set off alarm bells in your head. If it doesn’t, then you’ve already fallen for the first trap of building software: deceptively simple.
To research any project/product that doesn’t exist will require asking a lot of questions and knowing whom to ask those questions of. Even discovering the right people is deceptively simple.
Perhaps the people are unfindable? What do we do then? Well, surprise! This is a risk! Identifying risks early on, and continuously throughout the project, is the best way to avoid being in the wrong place at the wrong time. As they’re mitigated, you can sometimes cross the risk off altogether by simply avoiding it, such as scope creep.
Remember that as you discover risks, the very act of mitigating them may introduce more risks. So, continuously reevaluating is a necessary act. Many people forget to do this, and get blindsided.
The Wrong Time
Projects are notoriously late in the software world. Why? Is there something special about them that makes them hard to get done on time? I think there is. Software engineers are a lot like cats, you let them out the front door to find some mice and they show up three days later wanting food and water.
This isn’t to say all software engineers are like this, and even then, it’s a gross generalization. Software engineers are solving hard, exhausting problems; communicating; and trying to convince a very literal object to literally do what they’re literally thinking … it’s deceptively simple.
Hey. I’ve heard “deceptively simple” before, it sounds “risky!” Indeed, a project being late is a risk of writing software. Or doing anything really. There’s things outside your control, like traffic, that you can do nothing about. So, we mitigate it by giving ourselves more time, right? Haha, no.
If you commute, you have two choices:
- Leave early enough to always be ready for any traffic.
- Choose a route that doesn’t ever have much traffic, but takes slightly longer in the worst case, or much much shorter in the best case.
A lot of people will choose option 1, because it’s the most obvious, the naive approach. Option 2 requires more planning and research to get right, but pays off with a very consistent commute. It requires exceptional events to be late with option 2.
However, if you’re still thinking about it, option 2 (in the real world) is not always a valid option. Sometimes your starting and ending points have a risky route. In the project world, we can change both easily and freely, if we pay close enough attention early enough in the project.
This can mean using existing libraries, or forking them. This can mean changing the scope.
Balancing
Often you’ll find that you can build “the right project at the wrong time” or “the wrong project at the right time.” Usually the former is preferred, but sometimes it’s the latter. It depends on the context, I suppose. Balancing these two is tough. Getting it right, for your context and politics … is much tougher.
All I can say is, good luck! Much of this balancing act requires communication and politics. And magically, is also a risk that can be mitigated. Mitigating these risks requires a little bit of thought and finesse though — getting it right, or getting it on time — the owners of the project will obviously say “both” and mean one or the other.