Part II: Limiting Scope Creep and Managing Risk
By Brian C. Dougherty, Director of Engineering
In a traditional project, scope creep must be managed tightly to keep things on schedule and within budget. Each change in scope must be analyzed to predict its impact on the project, then the various stakeholders can decide if the change is worth the cost.
But what about projects that are outside the norm—in what we at Ventures call the “innovation space?” Here a project’s scope is constantly changing as the technical team sheds new light on what is (or isn’t) possible or practical. Meanwhile, the client’s marketing team is daily gathering new information about what the market wants or needs. All of this puts nonstop pressure on a project’s scope, and in a well-run, fast-paced project, changes can occur several times a day. This means that if we followed a rigid change-control process that took only a day to complete, we would always be losing ground because of the rapidly changing project landscape.
That said, what is the solution to scope creep in the innovation space? Well, there really isn’t one. Scopes will creep and you have to expect it. Rather than spend a day of effort resisting the inevitable changes, stakeholders should agree that changes will impact the schedule. Attention and effort therefore should be directed at the detailed project planning that needs to happen in the innovation space. This planning includes special attention to budget and schedule issues, which will be covered in part 3.
In traditional project risk management, you consider the things that might go wrong, weigh their potential impact on the project, and assess the likelihood of each event. This gives you a weighted list of things to worry about so you can decide how far down the list you need to manage.
But what if you don’t know what you don’t know? In the innovation space it’s hard to predict what can go wrong when you’re not totally sure what is right. In the innovation space I prefer to focus on the tough problems at hand. I start with what is perceived to be the biggest challenge or unknown, and assign resources down the list until I run out of resources. Then I track progress on these items daily in order to keep good data flowing into my planning process.
One common risk to any project is that an outside vendor or component will fail to work as expected, costing a project valuable time. It’s easy—based on reading a webpage, datasheet, code documentation, or sales brochure—to assume that a service provider or component will do exactly what you need. You may be weeks into a project before you discover something peculiar to your system is causing a particular component or service provider to fail and changes must be made.
So never assume smooth sailing. Things go wrong, so it is important to have contingency plans and to have multiple plans running in parallel to mitigate the calendar impact when one plan fails. In short, if your project hinges on a silver bullet, don’t relax until the werewolf is dead.
Next month we’ll finish this series on the innovation space by considering scheduling and budget, quality management, project planning, and communication.