In spite of all the best practices and project management techniques, scope creep (and resulting delays and cost overruns) has always been the biggest problem on most development projects. The only way we are going to solve the scope creep problem is to understand and deal with the underlying dynamic that creates scope creep in the first place.
 
This dynamic has two drivers. The first driver arises from the fact that the more we analyze a situation the more complexity we discover and so the more complexity we add to the design of the system. The second driver arises from the fact that most business people have been through system development projects before and they know there will never be a “phase two” on the project (in spite of what anyone says). They know they’re only going to get one shot, so they try to think of everything they might ever need and they push for all those features to be included in the first phase.
 
These two drivers set up a self-reinforcing cycle that leads to an infernal, downward spiral of mounting problems. Lots of analysis is done, lots of complexity is discovered, people feel they will need lots of features to deal with all that complexity and they insist on getting all those features in the first phase. There is a palpable lack of trust between the business and IT people because of this. Inevitably the design requirements call for a system that is way too big and way too complicated; chances of building it on time and on budget are slim to none, and IT is almost always the party who gets the blame.
 
The answer to this downward spiral is simple yet also counterintuitive. The answer starts by doing less analysis (not more), a LOT less analysis than is usually thought necessary. Restrict analysis to only what the business people need right now; do not spend time speculating on what they may need a year from now. People know what they need right now because they’ve already thought about that and they can usually tell you in 30 minutes or less. It’s when you start asking people to speculate about what they’ll need one and two years from now that things get complex.

Because you focus ONLY on the here and now, you can do less analysis and you can quickly design a system that gives people that handful of useful features they really want right away. And because the design is therefore relatively simple, you can also build the system very quickly and put it into production.

If you deliver the first version of the system in a 30-45 day timeframe, you will totally surprise (and delight) the business people. They will start using the system right away and they will thank you for making their lives easier. Yes, they will thank you. And they will tell you they didn’t think you could get a system delivered so quickly, and they will start to trust you when you say there will be a phase two on the project.

And then, after a few weeks, you start working with the business people on the next round of features they want to add to their system. They will have had time to work with what you just gave them, and they will see what they need next. Again you are only asking them to tell you what they need right away, they are not being asked to speculate about vague and complex possible future needs.

This agile and iterative system development approach is the way to side-step

You do not have flash or javascript support.

Average (4 votes)

Reply