cazh1: on Business, Information, and Technology

PM Anti-Patterns That Increase IT Project Cycle Time

Lots of conversation at work these days about PMO, resource prioritization, and reducing cycle time for IT projects. I feel a series of posts coming on ...

IAPL, we launched a project to bring test discipline to our technology efforts. The team was writing standards and guidelines for test scripts, implementing integrated testing tools supplied by the ERP vendor, and adding steps to our project methodology requiring test scripts for all system changes. As the project dragged into a fourth month, I prodded the team to do a partial release - show the testing standardsto one or two project teams, and get their feedback when the standards are applied to "live" projects. We could stress-test the process, validate our assumptions and identify areas where the developers are [predictably] going to resist this extra work.

The idea met with resistance from the team; I kept hearing that we had to have a 100% complete solution, soup-to-nuts, before we show it to anybody. This would be a triumphant introduction, anticipating and answering all questions. The debut would be followed by the flawless rollout, which would achieve 100% compliance because the solution was intuitively obvious.

Stinkin' Thinkin'

Okay, I exaggerate a little - but there are a couple of treacherous antipatterns in here, including ...

• The Magic Bullet
  
  If I only had a "system" I would able to solve my problem
  I can't do anything now because I don't have the full system done yet
  I can't increase sales without buying this million dollar CRM system
  
  Waiting for 100% completion before showing it to your potential end user assumes that you completely understand the requirements - a rare feat. It also reflects the mistaken belief that the 100% solution will magically eliminate resistance and work flawlessly the first time.
  
• Field of Dreams
  
  Everyone buys the value of automated / structured testing
  Our development teams will concur immediately and comply faithfully
  
  Even if the entire organization agrees with the concept - this still represents change. These are newly required tasks that I didn't have to do in the past. Simply put - this is More Work, with only a theoretical, long-term value ... so what's in it for me right now?

Reduce Cycle Time with Staged Deliverables

I absolutely prefer the Staged Deliverable approach; multiple releases of working processes, demonstrating speed and concrete progress to the business while enabling more granular requirements validation and acceptance testing. The business gets to see tangible progress in a short time frame, and can identify and understand problems in the requirements before they get baked into a complicated application.

Root Cause, and Counter Strategies

Of course, there may be a deeper issue at work here - the almost desperate need to hold on to technology resources. How often have you worked on a project where the business keeps adding "just one more" feature before they'll complete the final acceptance review, and allow the project to be marked "done"? This is just a symptom of a common IT challenge - we all have more work to do then hands to do the work. Savvy business groups don't want to call the project "closed" because all the resources will go away -so they'll try to stuff more features in, expanding the scope of a project to keep the developers engaged for their pet projects.

Part of the tactics of a staged deliverable approach include a focus on the 20% of the project that delivers 80% of the value. Getting the majority of tangible results in a very short amount of time may be enough to satisfy the project sponsor - especially when they begin to understand that it will take (say) four times as long to deliver a much smaller incremental benefit.

Also - establishing a track record of rapid-fire deliverables will get your business users out of the mistaken belief that all projects go on for months.

Previously ...

• The "Army Rangers" model for IT Professionals (January 02, 2006)
• Misapplying the Pareto principle (January 07, 2006)
• Who Pays for IT Infrastructure? Business projects! (March 16, 2006)
• War Stories from the Change Management front (August 21, 2006)
• The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
• Driving to a Decision on your Projects (February 10, 2007)
• Five Key Skills for Successful Project Managers (June 18, 2007)
• The Five Fundamental Rules of Project Management (October 15, 2007)

Technorati Tags: business value, Project Management, tech management

posted by James P. MacLennan at 11:15 PM | Permalink | 0 Comments