Not recorded

Avoiding the "Dark Twisty Turn-filled Tunnel Syndrome"

Stakeholder Management | By Bob McGannon | Read time minutes

Young man standing in a dark tunnel

Many a well conceived project ends up in the scrap heap because of inadequate expectation setting, or sponsors and key stakeholders that become disinterested or impatient with projects that don't produce deliverables quickly enough. These projects, after creating an initial buzz, appear to enter "a dark twisty tunnel" where the light from the tunnel entrance is no longer seen, the tunnel exit is nowhere in sight, and inadequate milestones exist to indicate forward progress. Avoiding this trap is no trivial matter, as it is more than just defining milestones for your project. Intense planning, extra care with estimating, and segmenting your product solutions into meaningful phases are critical to avoiding this "dreaded tunnel." Here are our recommendations for keeping your project in "the light of day;" avoiding cancellation or a drop in priority due to the "dark twisty turn-filled tunnel syndrome."

Define Meaningful Milestones

Milestones are a basic part of every well constructed project schedule. They establish points in time where significant events have been carried out, deliverables have been produced, or stage gates have been reached. Often these milestones are inserted in the schedule by project managers without applying a long term view to managing stakeholder perceptions. Certainly, there are "natural" milestones such as reaching stage gates which are appropriate. However, if one defines and applies milestones with an eye toward demonstrating meaningful business progress, a greater good comes from these indicators of progress on the project. The key to making this work is to tie milestones to events that stem from the business purpose for executing the project. Thus, milestones can (and should!) be defined prior to completing a detailed schedule.

Milestones that are meaningful to business sponsors can be derived as part of, or shortly after, the creation of the project charter. These can then be modified as initial planning and solution concept development are completed, with involvement from the sponsor and key stakeholders. These milestones, created and modified with customer involvement, are then inserted into a detailed project schedule, along with the project progress milestones such as the entering of a stage gate.

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 utilise 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 organisation'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 finalisation 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.

Manage and Understand the Length of the "Trip"

Project triple constraints are established early in the project. True, they should change as more and more detail about the project and the required solution are discovered. Despite this, general parameters for the project are established early. A satisfactory timeframe for delivery - considering the magnitude of change, and complexity for the project, is determined early as part of the triple constraints. Yet, this is often forgotten as change requests are processed, business changes cause priority adjustments, and unexpected events are encountered by the project team. We have a tendency to focus on the micro level of change, and forget about the macro project timeframe - what we originally used to justify executing the project in the first place! Managing the project macro level timeframe requires the following:

  • During the early planning stages of the project, set a desired duration for the project, and an "acceptable risk duration." The acceptable risk duration is a duration that is longer than originally anticipated, yet is still reasonable and comfortable for the business customers and project team. This risk duration should consider the degree of business volatility, the competitive landscape for your application area, and the ability to retain the appropriately skilled team members for the planned duration.
  • Providing focus to the long term impact of accepting project changes. Standard change processes should apply for any project. At some point however, ideally as the "acceptable risk duration" is approached, the entire project scope should be re-evaluated. All changes that aren't completed should be reconsidered and prioritised. Scope - at the macro level - can then be evaluated to ensure the project stays within acceptable timeframes.

The dark and twisty tunnel is a lonely place for a project manager. Diligent planning, mindful scope management and an eye toward the big picture, in addition to typical change management procedures can keep you projects vital, and your customers happy. It's not bad for your personal sanity either!


Bob McGannon is a Founder and Principal of MINDAVATION, a company providing project management training and consulting, leadership workshops and team building programs throughout North America and Europe. Bob can be reached at MINDAVATION via the web at MINDAVATION.COM or by calling 866-888-MIND (6463).

What's Next?

You may also be interested in