Download the Article (PDF, 61 KB)
Patricia A. McQuaid, California Polytechnic State University
As software professionals enter the new millennium, regardless of what Fred Brooks (Brooks 1987) said, the search for the "silver bullet" continues. In his infamous paper, he likened software projects to werewolves, which transform the familiar into horrors. Of course, the only way to lay werewolves to rest is by using a silver bullet. Brooks states that "the familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products."
Software professionals have made technological advances, created new tools, followed a process improvement plan, utilized benchmarking, developed measurement programs, and performed rapid application development (RAD). Project management, however, is still not done well. Reasons for this include poor estimation techniques, lack of historical data, weak management commitment, inadequate or nonexistent processes, planning being done in a vacuum, the project plan and other plans not being synchronized, lack of effective software testing, and replanning rarely done, even if crucial factors change. This article surveys many of the important issues that project managers face while managing software projects in such a dynamic environment.
Key words: change management, personnel issues, planning, process improvement, requirements management
Quality management is still not understood, much less done
well. This is partly due to a lack of understanding of what
the quality functions are. Quality is still viewed as an overhead
function to be done only if the customer pays for it, and
too many projects do not realize the value added from quality
functions or resources. Even today, measurement data on quality
functions are largely ignored. In todays environment,
there seems to be an inability to manage the software engineering
process: processes are chaotic, there is a lack of engineering
discipline, and the quality framework and measurement discipline
is missing. In terms of people, the organization structure,
skills, and culture development, career paths are not clear
and motivation systems and compensation are not aligned with
business objectives. Organizations are hiring only for the
project and not considering the organizations long-term
hiring needs. There are often no product quality standards,
resulting in inconsistent product delivery.
There are many reasons that rapid application development projects, as well as software projects, generally fail. A core reason is the lack of project management training by the people responsible for the project, leading to unrealistic expectations and schedules, problems with requirements, and problems with the developers and customers. Software development is difficult to manage if the requirements cannot be fully and accurately defined at the beginning of a project or if the requirements are so complex that changes are inevitable during development, even when the time frame is short. The challenges of managing requirements and controlling resources tend to result in the familiar panic and crisis mode around the delivery time. There may be an absence of an effective configuration management system or a lack of customer involvement. As a result, the quality of the delivered product is poor, rework pressure is increased, and the employees become burned out. To further compound the problem, product testing can suffer greatly. Capers Jones reports that poor quality is one of the most common reasons for cost overruns and is also one of the reasons for nearly half of the cancelled projects (Jones 1994). In this article the author will define rapid application development (RAD), discuss the reasons for failure in more detail, and provide some recommendations to help alleviate these problems.
WHAT IS RAPID APPLICATION DEVELOPMENT?
RAD is a term for a project that emphasizes development speed and, if done properly, can be structured and disciplined. Despite the word "rapid," it is not intended as a "quick fix" proposition. RAD concentrates on the delivery of the product and involves the client from the start and focuses on the clients needs, uses an incremental approach, keeps the project plan updated, applies development fundamentals, and manages risks to avoid catastrophic setbacks. A major goal is to avoid what Steve McConnell (1996) calls the "classic mistakes," discussed later in this article. RAD is important because "The ability of an information system to evolve to meet new requirements is one of the key quality characteristics, but systems must also be capable of rapid evolution if they are to deliver real value to the business community in this volatile business environment. Systems that cannot evolve rapidly offer little or no support to their users, who in turn become less responsive to their environment and consequently incur increased risk of failure in the marketplace" (Hambling 2000).
Successful Rapid Development
Successful rapid development starts with understanding and defining the clients business needs, and then moves through the phases of high-level requirements to detailed requirements, to design, to prototyping, to development, and to implementation. Testing should be involved early in the project and throughout the development effort. One of the goals of RAD is to provide an updated "look and feel" of the evolving product and to allow the client to have hands-on contact with the product as soon as possible.
Throughout these phases, one must continually review and update the project plan, carefully controlling all change requests along the way. One must assess the risks to the project at the completion of each cycle and review the current understanding of the clients business needs throughout the project. The schedule must be accurately developed and carefully controlled. Most projects overshoot their estimated schedules by 25 to 100 percent, but some organizations can predict the schedule accurately to within 5 or 10 percent (Jones 1994).
Components of Rapid Application Development
Figure 1 lists the major components of a RAD project. Depending on which software development lifecycle one is using, it may or may not look similar to ones existing infrastructure. A version of the product is developed and is shown to the customer/client, and the product is refined based on customer feedback.
The goals of RAD include those of building in quality, preventing "feature creep," controlling the schedule, and maintaining a predictable ship date. The reality of RAD, however, is that often usability suffers, performance suffers, maintainability suffers, and testing is not adequately done. A successful RAD project must therefore be carefully managed.
FOUR DIMENSIONS OF DEVELOPMENT SPEED
According to Steve McConnell (McConnell 1996), there are four dimensions of development speed: people, process, product, and technology. These can be considered the major determinants of software cost, schedule, and quality performance. There is a point where the focus on these four factors becomes synergistic, as good practices tend to support one another. Associated with these factors are certain classic mistakes, those ineffective development practices that have been chosen so often, by so many people, with predictably poor results. If these mistakes are avoided, one may not be guaranteed rapid development, but if they are not avoided, one will certainly be developing at a slower pace. The author will first describe each of the four factors, and then address some of the most significant classic mistakes associated with the factors.
Dimension One: People
Software development is large-scale, integrated, intellectual work. Knowledge is the raw material of software development, and the software engineers are the people who transform the knowledge into software products. Software is the most knowledge-intense industry in history; therefore, organizations must find ways to increase the knowledge, skill, and performance of its software developers to increase the capability of their work force. Doing so will help the organization stay competitive in a global market, satisfy the exponential growth of software volume and complexity, and increase the quality and reliability of software systems to levels achieved by hardware.
To achieve the concepts in RAD, or any development methodology, an organization may need to change the way it manages its people in order to improve the skills of the work force, develop proud and satisfied employees, retain corporate knowledge, and develop competitive people. Teams can be formed in order to create and maintain competitive organizations. One must ensure that the software development capability is an attribute of the organization rather than the presence of a few extraordinary individuals. One must align the motivations of the individuals with that of the organization, and retain the "human capital" and growth so that it is unmistakably a corporate asset.
Dimension Two: Process
An underlying goal of process improvement is to remove defects early and efficiently from the software work products. One of the many benefits of focusing on process improvement (both technical and management methodologies) is that individuals develop the necessary skills and knowledge in order to perform their roles effectively and efficiently. This knowledge improves the understanding of how the organization develops software, helping to increase continuity. It is critical for the developers involved in the software project to establish a common understanding of the customers needs, not just the requirements, and to keep the customer involved in the development process.
One must establish reasonable plans for performing software engineering and for managing the software project. It is important to provide management with adequate visibility into the processes being used by the software project, the projects progress, and of the resulting quality of the products being built. An important part of measuring the progress of the project is estimation: one should estimate the size of the product, the effort, and the schedule. Estimating the size of the product is difficult, and many organizations use function points for this type of estimation. The effort estimation is not as difficult, but only if there is historical data on similar projects performed by the organization. Once these estimates are calculated, it is then possible to estimate ones schedule. It is helpful to provide estimates in ranges and associate probabilities with these ranges. Once these estimates are made, it is important to monitor and continually reassess what one has planned to control the development schedule.
Improving software development processes will lead to reduced rework. This reduction in rework leads to reduced development cycle time, giving increased predictability and control of software quality and a reduction in the number of defects. Another benefit of process improvement is that it can provide increased control of costs and, therefore, the ability to predict both the development cycle length and costs. This enhanced ability allows one to make cost-benefit tradeoffs of development methodologies, technologies, and processes. This level of control increases the ability to make risk management decisions based on quantitative data. One must also be sure to select and manage qualified subcontractors, because their success or failure could dramatically affect ones project. All of the benefits discussed result in increased productivity rather than on dealing with crises.
The Software Capability Maturity Model® (CMM) is perhaps the most widely used management-level framework for understanding, managing, and improving software development. The CMM is a model for organizational software improvement and is an underlying structure for reliable and consistent software development. The software CMM addresses widespread problems in managing software projects, including quality and productivity issues. By using professional judgment, the CMM can be used across a wide range of size, application domain, lifecycle, development, and maintenance environments. The hierarchical structure of the CMM supports variations by rating processes at the key process area (KPA) goal levels and by using the KPAs, subpractices, and examples as guidance for improving software processes. Factors that must be considered when an organization is trying to establish its organizational processes can be found in (Kasse and McQuaid 1998).
Dimension Three: Product
Focusing on the product size and characteristics presents great opportunities for schedule reduction. The schedule may be able to be shortened by reducing the products feature set. In fact, the 80/20 rule may apply here: perhaps one can develop the 80 percent of the product that takes 20 percent of the time. If the feature set is flexible, one may be able to keep the look and feel of the product, its performance and quality characteristics flexible, and construct the product by maximizing the use of pre-existing code.
One of the largest contributors to the development schedule is the product size, so by striving to develop the most essential features or developing the product in stages, one can reduce the development time. Developing the product in stages may be a strategy to deliver components of the software, so that the user may start taking advantage of the product earlier. Defining and implementing the proper characteristics of the software product are critical success factors. Additionally, development effort may be improved by minimizing other product requirements, such as overly ambitious goals concerning performance, robustness, reliability, portability, and so on. As one can see, it is critical to involve the customer early and continually in the development process, which is one of the key RAD components. Negotiation skills are an important aspect of controlling the schedule and feature set.
Dimension Four: Technology
Development speed can be improved by moving from less effective to more effective tools. Choosing tools effectively and managing the associated risks is key to achieving RAD. An efficient implementation strategy is key to achieving RAD. One must be careful not to believe that it will be the new technology that will save the day.
As noted earlier, McConnell (1996) describes certain "classic mistakes," those ineffective development practices that have been chosen all too often, by many people, with predictably poor results. The goal is to avoid these mistakes so that one reduces the risk of slow development and achieves rapid development. The author has selected a subset of these mistakes for each category, those deemed to be the most important. The remainder of this section deals with these problems and proposes some recommendations.
Work done by Tom Demarco and Tim Lister (Demarco and Lister 1999), among others, has shown that people issues have more impact on both the productivity and quality issues than any other factor. Often, the organizational infrastructure is not properly in place to support the development and management of highly skilled and motivated people. All too often project managers are trained on technical matters and not enough on people management. As a result, these kinds of managers may generate high employee turnover. Often, if a project is in a crisis, people may be added too late to the project in the hopes of meeting the deadline. It may take six months or more, however, to have a productive employee (McConnell 1996). To further add to the problem, heroics are often rewarded publicly and true successes are often left unnoticed, leading to frustration by all employees involved in the project.
For many years, software developers and engineers have worked on their own, writing programs and developing software. But now, times have changed and teamwork is highly valued. The ability of people to work in teams is another skill which, while it is intuitive for some, must be learned by others.
It is critical that project managers be trained to effectively manage their employees. To provide guidance on these issues, Watts Humphrey of the Software Engineering Institute has developed the Personal Software Process® (PSP) (Humphrey 1996), a software process that is based on quality management principles to be used by an individual software engineer to help manage and improve performance. With PSP engineers use process management principles, measuring and analyzing their processes to improve the accuracy of their plans and the quality of the software they produce. The PSP quality strategy stresses that low defect content is an essential prerequisite to a quality software process. The personal level is where defects are injected and where the engineers should remove them, determine their causes, and learn to prevent them. There is also ample material related to managing software developers available from practitioners in the field, such as (Demarco and Lister 1999) and (McConnell 1996).
More and more projects are being undertaken in teams, and the importance of group dynamics for those developers working in teams cannot be over- emphasized. To provide guidance to the problem of working in teams, Watts Humphrey has also developed the Team Software Process® (TSP) (Humphrey, Lovelace, and Hoppes 1999), which extends and refines the CMM and PSP methods. It was developed to help software engineering teams build quality products within cost and schedule constraints and to accelerate software process improvement. It provides guidance to organizations in building a self-directed team and performing as an effective team member in both development and maintenance work. It also shows management how to guide and support these teams and how to maintain an environment that fosters high team performance. Demarco and Lister, as well as others, have also published a number of books and articles related to managing teams. Fortunately, many universities are incorporating a great deal of teamwork into software development, software testing, and project management classes in both business and engineering curriculums.
Process-related mistakes hamper development by wasting the time and effort of the developers. A central problem is having poorly defined software development processes, procedures, plans, guidelines, and templates.
Very often, projects get off to a bad start because scheduling is done by upper-level management and/or marketing, resulting in overly optimistic schedules. Even when software developers establish a well-defined schedule, it is not uncommon for others to modify the schedule to fit their needs, thereby increasing the risk of failure. It is critical to identify, address, and eliminate sources of risk before they become threats to the project, so organizations must have an adequate risk management focus. Some organizations have the "code-ship-test" mentality. Having an inadequate understanding of the necessary quality functions throughout the lifecycle clearly results in the production of bad software. Too often there are insufficient management controls and oversight into the processes being used on the projects and their ability to produce the necessary product quality.
Without a strong configuration management process, problems can occur, such as the following: the latest version of source code cannot be found, a difficult bug that was fixed at great expense suddenly reappears, a developed and tested feature is mysteriously missing, or the wrong version of the code was tested. Finally, a fatal error is for an organization to abandon planning and most other processes when under pressure, when controls are most needed.
Quality must be designed in from the start and not short-changed during the development process. Quality assurance (QA) fundamentals must be in place, including the development of a quality plan. QAs role is to ensure that the project is developed in compliance with the defined processes and that the processes defined are adequate for the project. It also provides feedback to the projects management about the effectiveness of the processes the developers are following and provides feedback to the process group about the usability of their processes.
Configuration management is the backbone of the development process and helps ensure product quality and process improvement. It involves identifying the configuration of the product (that is, selected work products and their descriptions) at given points in time, and systematically controlling changes to the configuration. It helps to maintain the integrity and traceability of the configuration throughout the lifecycle. It is a process that manages product evolution throughout its lifecycle and creates a verifiable history of the product as it matures. It enhances communication among project members and customers.
As part of the development process, not only must an organization put in place a risk management plan, but it must become a formal part of the development process. Schedules must be realistically set so that the scope of the project is properly defined, planning can be effectively done, and developer morale and productivity can be maintained. Requirements must be managed properly. If the project falls behind schedule, one should not abandon planning and "do whatever it takes" to finish the project, but take the necessary time to replan. One must adhere to the software configuration management plan to establish and maintain the integrity of the products of the software project throughout the projects software lifecycle. Additional information regarding configuration management and its impact on project management can be found in (Kasse and McQuaid 2000). A testing methodology must be emphasized, including unit testing, integration testing, systems testing, usability testing, user acceptance testing, and regression testing throughout the process.
Since one of the largest contributors to the development schedule is the product size, managing aspects affecting the size is critical to a successful development process. One common mistake is that of requirements gold-plating, those requirements included by the customer that are not essential. Related to this is "feature creep," those requirements that keep changing throughout the life of the project. Gold-plating need not be done by just the customer, but can also be done by the developer by adding features that were not requested by the customer, but that the developer feels the software needs. Clearly, inadequate control of requirement change requests can be fatal to a project. Not specifying acceptance criteria by the customer can be a problem. An often-overlooked consideration is assuming that if the product meets the specifications, the client will think it is a quality product. So, once again, for the reasons described here, it is important to continually work with the customer.
Gold-plating by either the customer or the developer must be carefully controlled, as does feature creep. Perhaps some of the desired features can be included in the next release, not the current release. If some feature needs to be included, then perhaps one can negotiate and defer a feature that is in the current plan or extend the deadline. All parties involved must be made aware of the effects to the schedule when requirements are modified and that the risk of missing the deadline is increased. Controlling requirements change requests is crucial to the success of the project, as is a strong configuration management program. Changes to requirements must be well documented, approved by all necessary parties, and tracked. Customer acceptance criteria must be defined, because how else does one know when he or she is done? It is important to involve all stakeholders in the requirement gathering and monitoring phases. A common mistake is to not identify all the stakeholders in the beginning of the project. Not only should one involve the users, developers, and customers, but one must not forget to involve the test teams and network personnel.
All too often, project teams search for the "silver bullet," relying on new technology to save the day. Perhaps the new language or the new hardware or the new tool will solve the schedule problems. Or perhaps the savings attributed to the new tool or method have been overestimated. There may be a lack of understanding that when a new tool or technology is introduced to a project, productivity will first go down before it goes back up, owing to the learning curve involved. Introducing the new technology to the entire organization too fast can cause increased schedule delays. Another problem is switching tools in the middle of a project. Between the learning curve and the rework involved, the benefits of the new tool can often be cancelled out.
Rather than relying on a new technology to save the project, emphasis should be placed on solid development principles, as described throughout this article. It is wise to phase in the technology in a controlled manner, if possible, rather than introducing it to the entire organization too fast. Of course, it is always safest to introduce the new technology on a project that is small in scope and not critical to the core of business operations, but often one does not have that luxury. Platforms are constantly changing, which adds to the challenge. An often-overlooked aspect is to remember to incorporate additional time into the schedule and money into the budget for training the employees in the new technology.
If one is to perform rapid application development, it is even more critical to have software process improvement initiatives in place and to follow sound software engineering practices. Organizations need to employ project management fundamentals, which include the tasks of estimation; the commitment process; planning, tracking, and control (measurement practices and risk management practices); software testing methodologies; and people management.
Brooks, F. 1987. No silver bullet: Essence and accidents of software engineering. Computer (April): 10-19.
Demarco, T., and T. Lister. 1999. Peopleware: Productive projects and teams, second edition. New York: Dorset House Publishing.
Hambling, B. 2000. Testing in a RAD Environment. Post-conference tutorial at the Sixth International Conference on Practical Software Quality Techniques, Austin, Texas: March.
Humphrey, W. 1996. Introduction to the personal software process. Reading, Mass.: Addison-Wesley.
Humphrey, W., M. Lovelace, and R. Hoppes. 1999. Introduction to the team software process. Reading, Mass.: Addison-Wesley.
Jones, C. 1994. Assessment and control of software risks. Englewood Cliffs, N. J.: Yourdon Press.
Kasse, T., and P. McQuaid. 2000. Software configuration management for project leaders. Software Quality Professional 2, no. 4: 8-19.
. 1998. Entry strategies into the process improvement initiative. Software Process Improvement and Practice Journal 4, no. 2:73-88.
McConnell, S. 1996. Rapid development: Taming wild software schedules. Redmond, Wash.: Microsoft Press.
Patricia McQuaid is an associate professor of management Information Systems at California Polytechnic State University. She has taught a wide range of courses in both the Colleges of Business and Engineering. She has industry experience in information systems auditing in both the banking and manufacturing industries and is a Certified Information Systems Auditor (CISA). Her research interests include software quality, in particular, the areas of software quality management, software process improvement, software testing, and complexity metrics.
McQuaid served as the chair for the Americas for the Second World Congress for Software Quality, held in Japan in September 2000. She will serve in the same position for the Third World Congress to be held in France in 2005.
McQuaid has a doctorate and masters degree in computer science and engineering from Auburn University, an MBA from Eastern Michigan University, and an undergraduate degree in accounting from Case-Western Reserve University. She is a Senior member of ASQ and a member of the Association for Computing Machinery, IEEE, IEEE Computer Society, the International Function Point Users Group, the Information Systems Audit and Control Association, and the Decision Sciences Institute. She can be reached at California Polytechnic State UniversityMIS, College of Business, San Luis Obispo, CA, 93407, or by e-mail at firstname.lastname@example.org.
The Software Capability Maturity Model (CMM), the Personal Software Process (PSP), and the Team Software Process (TSP) are registered trademarks of the Software Engineering Institute.
If you liked this article, subscribe now.