Guiding the Team Through Surprise Free Execution

When effort is put into finding the reason for a project surprise it is essential to make sure that future projects do not repeat the same mistake. Work through solutions with the team, gain consensus and add them to the library of actions to be used for future projects. Some would call this library best practices. I choose to call it same practices to signify that things are done the same way, project after project. Many may argue about something being the best but no one will argue the benefit to predictability when projects do things the same way, with the same expectations and deliverable requirements.

In simple terms the same practices library objective is in reaching absolute clarity of the who, what, when, where and how of every activity. To be clear - this is not the tasks in a project plan, it is the nuts and bolts details of activities and deliverables for every project action. Think of same practices as the source of information necessary to enable full clarity of tasks, objectives and deliverables for everyone working on the project.

Where are these same practices kept and how do you make them available to the team without becoming a burden to the users? The least effective implementations tend to be those that have a best practices document on a shared project drive on the network. It's far better than nothing but it's not optimal for the team. The best implementations are those that are web 2.0 based and contain the process sequence, the people, the plan, the schedule and the documentation all in one simple point and click user interface.

Where there is an ineffective atmosphere in place to guide the development process and same practices, project surprises should be expected. The magnitude of surprises will be reduced with an emphasis on a comprehensive process sequence and deliverable expectations along with a simple environment used to relay this information to users. When full clarity of individual objectives and deliverables are met, surprises will fade. This is not rocket science; it's people science!

Understand the Source of Project Surprises and Eliminate Them

What would enable every member of a new product development team to produce at such a level that projects flowed forward with negligible backtracking? You know, the backtracking that comes from failing to do it "right" the first time. The backtracking that silently eats into project efficiency, increasing costs and delaying revenue. Look back at those project surprises that caused a frenzied attempt to recoup what was lost. Why did they happen? Was it destiny, possibly fate, or was it because of a flawed assumption that should have never been made?

The last time a negative impact surprise made it's way into a project, what was the source? In most cases we will immediately conclude "something that was not planned, should have been". Although that possibility is certainly valid, it should not be assumed to be the end of the investigation. A project surprise usually means there will be backtracking to a previous task to rework something. It is essential that the root cause is uncovered whenever the project sequence is rewound to an already completed task.

More often then not when a task needs to be revisited it is due to a flawed objective of the task, the output or deliverable did not meet downstream expectations. That's not a timeline estimate issue; it's a task clarity issue that impacted the timeline! As dates for a project are developed, clarity is assumed, although often not ensured. Clarity of expectations will only result when two people (task deliverer and receiver) have consensus on when, what, how and where something will be provided. Reaching this agreement is a people thing, one where we can't depend on technology to make it happen.

In addition to a thorough project plan there are two crucial items that must routinely be addressed to keep surprises under control. The first one is to always consider the people aspect of a project's dynamics. Avoid a pure reliance on technology and methodology as the only guidance mechanism for a project. People know their function and are clearly capable of identifying an issue that impacts their productivity, if they are asked. The second one is related to investigation. If a project surprise occurs that causes negative impact to a project, it must be investigated to the root cause. Once uncovered, changes in the process must be made to ensure it will never be repeated on a future project.

The simple formula for eliminating negative project surprises is this - when something breaks the planned project flow, find out why by talking to the people involved and then do something about it. Technical tools and methodologies will be no help here, so put them away for this assignment. This one depends purely on people skills, so brush up on the one on one investigative skills that enable discovery of root cause. Do this well and enjoy a "Freedom from Project Surprises" that will lead to predictable and streamlined new product releases.