Scope creep. Virtually every software project suffers from it. Development teams start out with elegant and simple ideas. They toss them around amongst themselves and get excited about the prospect of delivering great software. They engage more people in the effort such as business stakeholders, power users, and senior managers. As they do, features get piled on — scope creep begins to spread like an infection.
Before long, what started out as a simple, elegant idea is now a complex, hodge-podge of loosely related features and functions. It happens for a wide variety of reasons. Though most commonly, it results from lack of vision and leadership. Unfortunately, vision and leadership can’t be taught in a training class or pulled from a text-book. If your project lacks them, you’ll need to do the best you can with what you have.
The good news is you can still build great software systems by relentlessly focusing on scope control. Start by delivering a strong message to the business community about the benefits of reducing scope. They need to hear the scope-control message in business terms. By reducing scope, they’ll get:
- Increased Value: How do you increase value? Deliver sooner. How do you deliver sooner? Reduce scope.
- On-time Delivery: How do you deliver on-time? Stay focused. How do you stay focused? Reduce scope.
- Improved User Experience: How can you improve the user experience? Put more effort into UX. How can you put more effort into UX? Reduce scope.
- Better Quality: How can you improve quality? Test more. How can you test more? Reduce scope.
- Lower Cost: How do you reduce cost? Build smaller systems. How can you build smaller systems? Reduce scope.
- Reduced Complexity: How do reduce complexity? Narrow the solution space. How can you narrow the solution space? Reduce scope.
- More Accurate Estimates: How can you improve your estimates? Take on smaller chunks of work. How? Reduce scope.
Do you see a pattern here? Smaller is better.
I know some will argue that, at times, business problems are so complex that the software has to be equally big and complex to solve them. While there’s some truth in the assertion that some problems require complex solutions, there are simpler ways to deliver those solutions. Start by decomposing the solution space into multiple components — loosely-coupled.
For example, use add-ons or plug-ins so that users who need additional complexity can install components while those who don’t won’t. The add-on components can be delivered separately by independent agile development teams allowing each team to stay focused.
Also, make the application configurable either via config files or a database. Let the end users decide how they want the software to look and behave. Focus on building flexible, rules-based systems not specific features. More rule types can be added over time — after initial delivery dates are hit.
Spend less time planning, estimating and arguing. Spend more time building and delivering by keeping scope under control.
photo credit: elycefeliz via photopin cc
Probably am not understood correctly, if so, its very funny, say i gonna give an example, DMV (Motor Vehicle dept.) want to have/develop a tool, wherein users can issue new licences/permits, renew existing ones, updates the existing ones (address etc), frame the ules/regualtions…these are all to individuals, in the same way, to driving schools, transport companies, so this is the requirements from the DMV, so as per this article, if DMV decides to do discard (reduce scope) of renewing functionality, update functionality, transport companies entity, then, let me know how the complete cycle/realirt requiremets fulfilled. As per this article, DMV can deal only with individuals, only with new license functionality, then obviously these 7 points mentioned above are OK, but the core requirements are aside, botton of the line, the developed tool is useless, hmmm
Thank you
Shiva, you raise a good point. We cannot remove “minimum” functionality. There are always core features that must be done. The point of this post is to focus on the core features and drop all the ancillary ones. For example, I could envision a license renewal system that includes the ability to see an image of the license complete with the driver’s picture. While that would be a cool feature, is it really needed? That’s the type of scope element that can be dropped, at least, initially. It can always be added later once the benefits of the new system begin to be realized.
Determining the limitation of a software project is crucial but you can perhaps use those limitations as future upgrades when the software is out in the market. You will know your software’s weakness and it will be smart to eliminate them to make it perfect.
Excellent point! We need to be learning before AND after the software is deployed.