Best-in-class report proves out commonsense guide: minimize change
By Staff -- Manufacturing Business Technology, 11/1/2005 7:00:00 AM
Change may be the only constant in the universe, but gone unmanaged, it wreaks havoc on software projects. A recent study from McLean, Va.-based Quantitative Software Management (QSM) found that managing changes in software projects is the key determining factor between best-in-class and worst-in-class endeavors. The differences between best and worst are—in software designers' parlance—"nontrivial." Best-in-class projects are said to be almost 3.5 times faster to market, and nearly 7.5 times cheaper.
QSM surveyed and researched more than 530 IT projects in 16 countries, with project focus ranging from ERP selection/implementation to e-commerce/Internet, billing, customer care, funds management, and inventory control on both mainframe and client/server platforms.
"Change in [software] requirements is the thing that causes so many projects to go awry," says Doug Putnam, a QSM partner. "It usually occurs in the last third of the project as pressure mounts to get it out the door. Teams compromise the original design and try to retrofit the changes back in, causing a lot of turbulence."
In addition to managing changes to requirements, other chief factors that work to separate best-in-class from worst-in-class include the skill level of team members, project leadership, and the availability and effective use of tools.
"One of the interesting things we picked up on had to do with the size of project teams," maintains Putnam "[Those teams] that attempted to overwhelm the project with manpower invariably fell into worst-in-class. It was the smaller teams—which had good project managers who would fight for reasonable schedules, pull the right people together with the right tools, get stable requirements, and give people a chance to do their jobs—that performed admirably. Those with unreasonable schedules [and numerous changes] were destined to be worst-in-class."
Curiously, although worst-in-class software projects result in about five times greater the number of defects, both classes—once released—resulted in similar bug-free performance, with neither running bug-free any longer than a day at a time.
"Both groups get to about the same level of quality during the test phase, and after about eight hours without a problem, they figure it's good enough to ship. It's just that one gets there faster and cheaper," says Putnam.
"Worst Mistake" This Restauranteur Ever Made
06/06/2009Hotels Give "Lean" a Bad Name??
10/30/2009Management moves
01/01/2004
Featured Company
Most Recent Resources
- FICO™ Xpress Optimization Suite Schedules Big Profits For Clients
- Strategic Pricing: Three Steps to Higher Profit Margins
- Driving Innovation Through Lean Product Development Practices
- Demand Planning Maturity Model Strategies for Demand-Driven...
- Simulation-Driven Product Development:Will Form Finally Follow...
