While working through the creation of meaningful milestones, care should be given to ensure that “technical solution language” doesn’t creep into the milestones. It does little good to talk with a non-technology minded sponsor about a technical concept such as creating an IT data model. Although this is a significant milestone in the creation of an information technology product, it has little relevance to a manager who is trying to decrease process turnaround time or cut business costs! It is certainly useful to include technical milestones to track progress from the technical team’s perspective, but to utilize those items, and those items only, as project milestones for business stakeholders is an invitation to trek through a very long “tunnel.”

Milestone creation and tracking is something that should not be taken lightly!

Break the Project into Phases – 9 Months or Less

The most fundamental way, yet often the most difficult way to avoid the “twisty turn-filled tunnel” is to avoid the temptation to create a long single-phased project. A fundamental principle of the “agile” project methodologies, smaller projects or larger projects broken into delivery phases are very effective in keeping the organization’s stakeholders interested in the project. Stakeholders are simply more engaged because they receive project benefits early and often.

While this approach is relatively straightforward for some projects, others, such as a large ERP implementation, can be more difficult. These more complicated and extensive projects should be planned in phases, with a degree of functionality introduced at regular intervals. No more than nine months should pass from requirements finalization to delivered functionality! Planning a project in this way can be difficult, but it can be done, and the benefits of doing so are worth it. These benefits include:

• Avoiding issues surrounding changes in business priority or a lack of “a corporate attention span.” Projects are more likely to get done when business value is produced at regular intervals.

• Introducing change to the customer community at a magnitude and at a pace they can absorb. Long projects that produce large deliverables introduce a considerable amount of change all at once. This alone can create change assimilation issues for end users, can exacerbate business process issues and generate disenchantment with the project. Keep the changes small, deliver them regularly and you’ll more likely to have happy customers.

• Keeping the business requirements fresh. Longer projects often have issues with scope creep and changing requirements simply because the business the project is supporting doesn’t remain static. This is a fast paced business world, and it shows little to no signs of slowing down. Longer projects simply deliver against requirements that are stale or obsolete. Keep the cycle (or phases) short from requirements verification to delivery and you’ll have fewer problems with obsolescence, and requirements volatility.

continue>>

<<back