Monday, December 30, 2013

How to Tank a Project 101 - THE DATE

Last blog post I talked about the problems with communications in the IT industry, and how those problems result in projects that are perceived failures. Generalities are important, but now it's time to get to some specifics.

The single most important metric for determining the success or failure of a project is THE DATE. You know which one I'm talking about - the date you set for the completion. Completion of what? Yep, that's part of the problem.

While THE DATE might be treated as the most important metric, it's actually one of the worst. It holds no real measure of success or failure, since it provides no understanding of whether or not the project actually met the real goals - solving the problems or making the improvements that were intended. What's worse, THE DATE is often arbitrary, while the goals are not. And yet the goals are often sacrificed for the sake of the date - how does that make any sense?

I think our obsession with THE DATE comes from our educational process. We are taught that hitting the date set by the teacher is all important, no matter the cost. And it does matter in that situation, since learning is a time based function. But once we're in the real world, other factors apply. Too often, we ignore these other factors, and continue our obsession with THE DATE.

So how does this all important metric get set? With all the diligence and care you'd expect with something so critical? Usually not.

Does this sound familiar? Someone with a 'chief' or 'vice president' at the start of their title stops you in the hall and says "I read an article in an in-flight magazine about the Cloud - how much time do you think it would take to move our swizzlestick production systems to a model like that?" You look like a deer caught in the headlights of a Mack truck. The sheer number of factors that will alter and influence a project of this type cause your brain to momentarily lock up. You start weighing your career options - the fast food industry can't be that bad, can it? You hem and haw, and the boss senses your fear. Usually they follow up with something like "Don't worry - I won't hold you to it. I'm just trying to get a rough idea." So believing that if everything in the universe aligned perfectly you might make it in 6 months and knowing that you'd better not take more than 12 and keep your job, you blurt out "around 9 months or so". You part company, and feel pretty good about it. After all, they will go through a process of requirements gathering and goal setting before finalizing the date, right?

Let's pretend this conversation takes place next week, during the second week of January. And before you know it, you see a project pop up on the planning calendar for 'implementation of Cloud architecture for swizzlestick software' with a completion date on the 1st of September. Not October, which would have been at least 9 months from the conversation, not even a general announcement of September, but a specific day that you'll never make. And that's how you derail a project before it starts, because now, best intentions aside, that's THE DATE.

This isn't how it plays out every time of course. Sometimes there's a bit more discussion, sometimes even some basic goal setting and requirements gathering. Some due diligence gets performed. And it's the right time to set a date - you can't run a project without one, of course. But even then, we set THE DATE without consideration for reality.

Let's go with a better scenario. Data is gathered, goals determined, basic requirements understood. And let's assume your team is extremely good at reviewing requirements and giving estimates. Extremely good is going to be 80% accurate at best at this early stage of any project - I think 60% is a far more reasonable number, considering the number of issues that can arise over the course, but we'll give it the benefit of the doubt and go with 80%. That means a 9 month project could be off by 7 weeks - almost 2 months! - and still be within the original estimate window.

Now let's be even more honest: when was the last time your team was 80% accurate with the initial estimate because you finished 7 weeks early? I didn't think so. The reality is that being 80% accurate in estimating means at best you'll hit 9 months, at worst it will be 11.

In an attempt to make it even more difficult for us to hit THE DATE, we refuse to accept any generality. At the very start a go-live day is picked, and that's what will determine success. If you start this 9 month project on February 1st, the go live WILL be October 31st. That day. Not the 30th, and certainly not December 1st. Since missing this day by a small amount won't become apparent for months into the project, this specific day will become firmly cemented in everyone's mind. Any slip means failure.

To highlight just how ridiculous this, consider a project with a fairly solid, tried and true estimation - having a baby. Odds are far better than 80% that it will be a nine month project, and yet no one is foolish enough to pick their child's birthday before they're even pregnant.

In all this focus on THE DATE, we lose sight of the goals. This project was proposed for specific reasons. There are cost savings, or efficiencies, or increased revenue at stake. When THE DATE becomes the most critical metric, we become willing to abandon features and functions, cutting back on the actual deliverables. It's a long proven fact that people will work to the metric that they are rewarded for. Did we get a system or process that still gave us what we wanted in the first place? No, but we hit THE DATE.

Is it possible to still manage a project to an successful completion while treating THE DATE differently? Yes, but it requires being smarter about how we pick THE DATE, and how we go about managing to THE DATE. And that will be the subject of our next blog post!

- Michael Crawford