We’ve all seen some pretty insane technology projects – everything looks great at the outset but by the end (planned or actively terminated) of the project things have unraveled. The hard part is figuring out how. There are tomes of analysis of project failures, ranging from requirements mismatch, insufficent time/resources to meet scope, and many other factors. If you are deep into project management go ahead and read through that (see here, here, and here if you want to do this – warning – could be painful! Good luck – these usually isn’t presented from an operational view). For the operators out there I’ll throw out a few red flags and bad smells that I’ve come across.
BTW – a “bad smell” is one of these semi-unquantifiable things where your instincts tell you something is wrong, but nailing it down to an exact detail isn’t necessarily simple. I call this “semi-unquantifiable” but if you really wanted you could do an after action review of the times that you had that “bad smell” feeling and ignored it – there will be multiple factors that contributed. By that point in time it is too late and the analysis will just reveal that you were right along with showing you why. The key here is to trust your gut – or the gut of someone that already has the scars from ignoring bad smells in the past.
Here are a few red flags and bad smells that you can use to guide you down your project path:
- Tech First – in any project where the technology is driving the solution I smell imminent failure – red flag territory. It isn’t certain failure but unless the operational (business) needs are elevated to top priority, things aren’t looking good.
- “We can train for that” – If a technology is cumbersome or imposes process that isn’t natural for operators you’ll be fighting an uphill battle. Think about how many folks you know that took training to use Facebook (know any?). Tech needs to be that simple if it is to be easily adopted.
- “The requirements say (or don’t say) …” – When a project manager has to fall back on requirements that were likely never done well you’re in trouble. Requirements generally don’t capture operational processes well (especially since they evolve as good solutions come along) and things like “ease of use” are impossible to quantify. Requirements should be a backstop – you go there as a reference but the business/operational success of a technology is rarely going to come from a requirements focus.
- If you looked at the analysis links I provided you’ll see a theme about poor requirement analysis causing failures. This point may sound like I am down on requirements. I want to be clear – requirements are key. However they MUST be done with an OUTSTANDING level of effort (an excellent job is NOT enough) and they aren’t the only game in town.
- Knowing exactly where the project will end – any project of significance (a 3-month project can be very significant – time isn’t the factor) that is “fully known” is deep into red flag territory. The successful projects are executed knowing that something needs to be improved and they start with a general destination in mind – of what can be improved and how. Then they learn while they improve. A project that focuses on the vision that was created many months (or years) ago is going to be missing the opportunities that present themselves along the way.
- Not involving the Operators – if your project doesn’t have active and passionate involvement of the operators that will be using the technology you may as well pack up, head home, and save the resources (time, money, and people) for other things. You MUST have active and passionate involvement – there will be times where you’re convinced that the operators and techies are going to start physically fighting but they are just working through the hard parts. Breaking through those hard parts is where the magic is.
- Not Speaking “Ops” – The end client’s language/lingo/terminology rules the day here. If things can’t be explained to the Operators in language that they understand you’re likely in the middle of a disconnect and you won’t know until the pieces come together. As an engineer I provide a service. I literally serve my clients and if I can’t use their language I don’t understand them well enough to serve them.
If you hit some of these themes you’ll likely have a queasy feeling and try to suppress it – that’s totally natural. Sometimes a minor issue doesn’t matter in the grand scheme. However, if the feeling is strong or keeps happening you should back up and take stock. You may save the project, or even better, you may make it even more successful than anyone imagined.
For those of you that are freaking out because it may sound like I am coming down hard on your project management approach – you should be freaking out… I kid partially here. I’m coming up with a flip-side post that provides guidance to allow you to support your operators – stay tuned for that (sign up below and I’ll get that to you directly).
If you found this helpful, I’ll be sharing more pointers, tips, and tricks here on the blog and through our newsletter. Just sign up right below and I’ll get this info to you regularly.
