Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

Avoiding the "Dark Twisty Turn-filled Tunnel Syndrome"

~ By Bob McGannon

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


Be the first to comment on this article.

Add a comment

(never displayed)

What is the day after Thursday?
Notify me of new comments via email.
Remember my form inputs on this computer.

Extreme Project Management

The running back dives for the first down with the defender on his back

Three war room strategies to try when you need to bring life back to a dead project, or save an engagement that is on the brink of disaster.

Four Steps to Project Time Management

Man pointing at an alarm clock

The four steps outlined in this article will help you better define and measure the activities that make up your project timeline.

Break Your PMP Studies Into Small Pieces

A mature student concentrating on her studies

Taking the PMP exam is one of the biggest steps you'll take in your career as a Project Manager. With careful planning you can pass with a minimum of stress.

Introduction to Scrum

Rugby scrum in a big push

Scrum is one of the simplest agile methodologies and is proven to be highly effective for software development and more general product development.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.

Latest Comments

Mind, Meditation and the Project Manager
- Thu 25 January 2:19pm

Arthur commented on…
Make Me a Project Manager in 2018
- Tue 16 January 12:24pm

Suzanne commented on…
The Role of the Project Manager
- Thu 11 January 9:29pm

Latest tweets

General Project Management • Re: Any Complete Project/Workflow Management Online Tool? #projectsmart #pmot about 8 days ago

General Project Management • Re: What degree should I choose to further my career? #projectsmart #pmot about 15 days ago

General Project Management • Identification System for Project Management Methodology #projectsmart #pmot about 26 days ago