Almost all development organizations, and most large projects, reach a point when communication breaks down and it becomes necessary to formalize management practices.
This raises a number of questions, such as: Is there a correct way to manage software development? When is it appropriate to apply a rigorous methodology? Does the introduction of procedures stifle innovation and slow down development? Why can some organizations develop software successfully with, apparently, no defined process?
Pointing to companies like Raytheon, Motorola or Boeing’s Space Transportation Systems, proponents of structure and discipline tell us that we can realize significant productivity and quality improvements when we use standards like ISO 9000-3, or work through the five levels of the SEI Capability Maturity Model. They extol the virtues of standardized project plans, task-level tracking, scope and risk management, structured walkthroughs, and defining requirements correctly before designing or coding.
On the other side, many people who develop applications for the Internet say it takes too long to write requirements documents, prepare module designs, and write test plans. Instead, they begin coding almost immediately, work interactively with users to refine requirements, and incrementally enhance the application through time.
They are prepared to re-write the entire application once they have a good idea of what the user really wants and how it should work.
Which approach is correct? Both are, and so are many intermediate approaches that fall in between. The key is knowing when it is appropriate to use which approach. Here are some of the factors to consider:
Size. In general, larger project teams require more rigour because managing communication and functional decomposition becomes more challenging. Small teams should not be burdened with the complexities of managing large initiatives. However, there is not always a direct correlation. NASA will apply far more rigour to building a small module for the space shuttle than will a company building an inventory tracking system.
Budget. Microsoft can spend over $100 million on an application and create teams with 400 members (the teams for Office, Windows 98 and Windows NT ranged from 200 to 450 people). But they can use less formality because they can afford to permit iterative enhancements to loosely-defined vision statements, supply buddy-testers for each developer, and build releases nightly. A typical company that is building a custom Internet-based ordering process cannot afford to use this creative Microsoft approach.
Pricing Model. Development performed under a fixed-price contract will require tight control with up-front scope definition and rigorous change management procedures. Fewer project controls are necessary if development is performed on a time-and-materials basis or a work-to-budget approach.
Time-to-Market. For a new product, with an opportunity window of only a few months, it may be necessary to follow a very intense, but unstructured process to implement a concept in software. When replacing a mature application that is nearing the end of its service life it is more appropriate to define processes that specify the design of the replacement system, migration strategy, and development life-cycle.
Other factors that should be considered include: amount of design or code reuse, repeatability of processes, experience levels of project teams, level of risk exposure if the project fails and expectation of technology change.
There are degrees of discipline that can be applied to the development of software along a continuum, from very casual with no formal procedures to rigorous with many procedures. One size does not fit all development organizations. Project managers must think carefully about what processes, techniques and tools are appropriate within their business context. The essential point is that we must consciously determine the optimal level of discipline to achieve the highest degree of project delivery success.
Hughes ([email protected]) is a vice-president of software development for EDS Systemhouse in Toronto. He is currently project director for Ontario’s Integrated Justice project.
