More excerpts and notes on classic mistakes… this time on process-related ones…
- overly optimistic schedules – sets a project up for failure by underscoping the project, undermining effective planning, and abbreviating critical upstream development activities such as requirements analysis and design. puts excessive pressure on the team, which hurts long-term team morale and productivity.
- insufficient risk management – only one thing has to go wrong to change your project from a rapid-development project to a slow-development one.
- contractor failure – getting contractors is sometimes done to alleviate pressure off the team. but contractors frequently deliver work that’s late, unacceptably low quality, or that fails to meet specifications (Boehm 1989). risks such as unstable requirements or ill-defined interfaces can be magnified when you bring a contractor into the picture.
- insufficient planning – if you don’t plan to achieve rapid devt, you can’t expect to achieve it. it’s wishful thinking to think it will magically happen on its own.
- abandonment of planning under pressure – project teams make plans and then routinely abandon them when they run into schedule trouble (Humphrey 1989). the problem isn’t so much in abandoning the plan as in failing to create a substitute, and then falling into code-and-fix mode instead. after abandoning the plan, the work becomes uncoordinated and awkward. and it’s downright confusing when you’ve no idea on what’s happening and on who’s doing what.
- wasted time during the fuzzy front end – it’s not uncommon for a project to spend months or years in the fuzzy front end and then come out of the gates with an aggressive schedule. it’s much easier and cheaper and less risky to save a few weeks or months in the fuzzy front end than it is to compress a devt schedule by the same amount.
- shortchanged upstream activities – the results of this mistake — also known as “jumping into coding” — are all too predictable. rework! projects that skimp on upstream activities typically have to do the same work downstream at anywhere from 10 to 100 times the cost of doing it properly in the first place (Pagan 1976; Boehm and Papaccio 1988)
- inadequate design – special case of the former; rush projects undermine design by not allocating enough time for it and creating a pressure cooker envt that makes thoughtful consideration of design alternatives difficult. the design emphasis is on expediency rather than quality. you end up with a design product which doesn’t actually help that much during implementation.
- shortchanged quality assurance – cut corners by eliminating design and code reviews, eliminating test planning and performing only perfunctory testing. result: product still too buggy to release. Shortcutting 1 day of QA activity early in the project is likely to cost you from 3 to 10 days of activity downstream (Jones 1994).
- insufficient management controls – few mgt controls to provide timely warnings of impending schedule slips; before you can keep a project on track, you have to be able to tell whether it’s on track in the first place.
- premature or overly frequent convergence – forcing convergence too early results to more effort as separate parts of the system aren’t ready and the people themselves aren’t prepared. extra convergence attempts don’t benefit the product; only prolongs the schedule.
- omitting necessary tasks from estimates – you still have to do these anyway. but without these considered into your estimates, you’ll look delayed or over budget.
- planning to catch up later – most likely, there is no later.
- code-like-hell programming – it is really just a cover for the old Code-and-Fix paradigm combined with an ambitious schedule, and that combination almost never works. it’s an example of two wrongs not making a right.