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 standards to 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.