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