what Alexexmachina says...

 

To Kill A Project: Part I - Timelines

 

Alexexmachina (Technical Specialist) Posted 11/2/2007

In my experience there are common behaviors, paradigms, attitudes and fallacies which permeate the management of IT projects that are directly responsible for the obscene rate of project failure. In the first part I'm going to talk about how unrealistic timelines will ensure failure.

The number one attitude I see blowing timelines and killing projects is something I call "false urgency". False urgency is creating a false atmosphere of time pressure for no justifiable business reason. An example of false urgency would be me insisting on an arbitrary deadline as though it weren't arbitrary. There are enough time pressures on a project team to make reasonable deadlines while hitting all the functional requirements and ensuring quality in the design and implementation of your solution. Why decrease your chances of getting something you actually want just because you've grown accustomed to our cultural 'I need it yesterday' syndrome.

Here's what you're either too busy to notice (or forgetting) when you rush an IT project: it won't get done like you need it to get done. Then you'll do one of two things, you'll throw it out, which means you've wasted resources, time, money, opportunity and demoralized the project team or, even more costly, you'll make a sunk cost justification (if you don't know what that is, read my post on sunk costs here) and try to salvage the project through endless iterations of continuous failure.

It's a lose-lose situation which will put a serious drain on your budget, your patience and your sanity. Is this the only thing causing unreasonable schedules? On rare occasion I've seen timelines emerge from real business requirements which have an absolute inflexible deadline. Although you can't really do anything to change those deadlines, there are other ways you can adjust.

Expect to hear this next bit from me over and over again: Time, cost, resources and quality requirements are inversely proportionate to the quality and scope of the deliverable. Duh, right? Because I'm a particularly slow learner when it comes to setting realistic expectations for individuals managing IT, I am continuously astounded that those individuals have managed to obtain jobs in management while failing to grasp that very simple concept. In case I was vague or you didn't catch it, I'll put it another way: you can't make a gourmet lasagna for four with no recipe, a broken oven, moldy cheese and $2.00 of ingredients. There are individuals out there who will tell you that you can, but I assure you they are either lying to you or they're idiots.

If you find either of these factoring into why your projects aren't making their deadlines, don't feel bad. I'm not actually suggesting that its simple or easy to manage project timelines and I don't have 10 steps to guarantee you can do it successfully every time. (if I did, I'd write the book and retire) But I have been fortunate enough to work with exceptionally gifted managers who taught me a sane way to get reasonable time estimates and work within time constraints. Next time you're ramping up a new project, consider this:

• Assess the business drivers behind the need:
  
  
  
  • Is there actually a fixed time line associated with the need?
  
  
  • If there is a fixed timeline, what additional costs can you support?
    
    
    
    • Additional budgetary costs?
    
    
    • Additional resource costs?
    
    
    
    
  
  
  • What consequences can you live with?
  
  
  
  


• If your requirements are reasonably complete, request a conservative estimate from the project manager.
  
  
  
  • Did he ask his technical leads?
  
  
  • Did they account for QA and bug fixing?
  
  
  
  


• If their estimate is unacceptable you have one of three options:
  
  
  
  • From the beginning provide whatever additional resources they need to complete the project.
  
  
  • Cut functionality down and plan future feature releases.
  
  
  • Start planning for the disaster recovery, because your project will fail.
  
  
  
  

Now, as I will talk about in my upcoming post on Defining Project Failure, qualitatively, some projects may 'fail' less than others and get you what you need by the date. But don't think those failures don't carry additional, sometimes hidden, costs. As someone who felt forced to leave a position because of constant, unreasonable time pressure, I can tell you that high turnover can be one of those costs.

I hope this has been helpful to someone. Unfortunately, my experience has been you either get this or you don't. Getting this point across to someone who's been managing IT projects under unreasonable deadlines for a while is near impossible. They believe that missing functionality, low code quality and missed deadlines are just part of the business. As someone who's seen it done right, I can assure you they don't have to be.