A General Rapid Development Strategy

The term "rapid development strategy" conjures up images of applying new and exotic techniques to the development process. The fact is, most processes can be significantly improved just by making them more efficient. Improving development schedules is no exception. The best strategy for rapid development is one that focuses on these four points:

1. Avoid classic mistakes.

2. Apply developmental strategies.

3. Manage risks to avoid catastrophic setbacks.

4. Apply practices that are oriented toward schedule improvement.

The first three points are those that any efficient developer would follow and should be common practice. However, organizations tend to ignore the obvious in favor of the silver bullet, which, sad to say, does not exist. But if the first three points are combined with the last bullet, which refers to three specific schedule enhancement techniques, the overall development process will be improved and shortened.

Avoiding Classic Mistakes

Organizations and project teams make a number of mistakes that have direct and dire impacts on development schedules, in particular, and on productivity, in general. Although there are many more common mistakes than are presented here, I have listed the four or five in several categories that seem to be the most prevalent.

People

• Lack of stakeholder buy-in. (This is usually the result of a poor stakeholder process or no stakeholder management process.)

• Unrealistic expectations. (They are often the result of promises made by the organization to the customer in order to secure the business.)

• Heroics. (A result of the inclination of project managers, or team members, who state their ability to accomplish unrealistic project goals in order to please senior management or customers.)

• Uncontrolled problem employees. (This mistake occurs when functional, or project, managers are unwilling to eliminate employees who don't fit in the organization.)

• Adding people to a late project. (This is a time-honored management technique to attempt to recover schedules. It often works in engineering and construction projects but has the opposite affect in IT projects, principally because of the learning curve.)

Process

• Overly optimistic schedules. (This occurs when an organization commits to an unrealistic schedule to improve a competitive position.)

• Insufficient risk management. (Risk management is one key project management function that is not generally done well. Too few organizations have well-developed risk management processes that support a proactive approach to potential risk events.)

• Insufficient planning. (Approximately 50 percent of the IT project schedules should be consumed with the planning and design processes. Instead, the tendency is to rush into the coding mode before planning is complete, sometimes before it is even begun.)

• Abandonment of planning under pressure. (Even when adequate planning has been accomplished, the tendency is to abandon the plan when things don't go well or when the project falls behind schedule.)

Product

• Requirements gold plating. (This often results when the seller attempts to give the customer more than he asked for. It usually ends with implied functionality, as opposed to contracted functionality, attempts by the seller to collect for work not originally requested, attempts by the buyer to obtain functionality not requested but implied, or all the above.)

• Feature/scope creep. (This usually results from the seller's desire to please the customer, that is, agreeing to small changes in the product without a documented change to the scope. One, two, or a few changes without a corresponding scope change usually are inconsequential to the schedule or budget. The cumulative effect of several such changes can destroy the project.)

• Developer gold plating. (Many developers and engineers are guilty of adding functionality to a product just because they discover a functional possibility as they develop the product. Even if the added function is a good idea, the schedule and budget will probably suffer if the customer does not formally approve the change.)

• Research-oriented development. (Products or subsystems that require research are not development projects—they are research projects. Attempting both in the same project inevitably results in longer schedules and more spending.)

Technology

• Silver bullet or magic bean syndrome. (Because of the rush-to-market requirement in IT, looking for one exotic solution to all the development problems is common and disastrous. Only sound, documented, implemented, and supported development strategies will improve the development process.)

• Overrated new tool and methodology savings. (This mistake is related to the silver bullet syndrome. It occurs when organizations buy the latest fads in tools or techniques in the hope that they will resolve any development or productivity problems.)

• Tools switching. (Once a project has begun, the tools used for development of the project deliverables should never be changed during development unless the swap-out was scheduled in the project plan, or unless the tools prove to be completely inadequate.)

• Lack of automated source-code control. (Uncontrolled source-code changes are still one of the most serious reasons for project failure. Change and conversion control processes are crucial not only for source-code but for scope and configuration as well. Without them, the project is doomed.)

Classic mistakes occur because they become so common that they are transparent in the work environment. As obvious as they might seem, classic mistakes must be identified, planned for, and eliminated. The result will be a significantly shortened schedule.

Applying Developmental Strategies

There are several fundamental strategies associated with development that also can improve schedules. Like the classic mistakes, most of these fundamental strategies are obvious. But like the mistakes, they are too obvious to notice without a conscious effort. The following strategies are categorized to focus attention on functions within the organization that need strengthening.

Management Fundamentals

• Schedule and budget estimating. (Nearly all schedules and budgets are underestimated because the organization does not have good estimating techniques and processes in place, does not support them if they do have them in place, and does not train people in the art and science of estimating. Another major problem is that senior management too often arbitrarily reduces the estimates for fear a contract can't otherwise be successfully completed.)

• Planning. (The planning function should consume nearly half of the project schedule, but because of the pressure to rush-to-market or because of senior management pressure to show progress, the tendency is to forget planning and start coding.)

• Tracking. (Project control is dependent upon a good tracking methodology and process. This process must include scope and configuration change management systems that are rigorously implemented and followed.)

• Measurement. (Measuring progress and measuring metrics are key to current and future project successes. Measuring progress means that the project management organization has in place methods, tools, and techniques for tracking the project tasks and for measuring variation from the established baseline. Measurements of metrics, such as numbers of defects, defect removal rates, or errors in coding, are needed for the project team to measure system quality and progress and to improve the estimating techniques for future projects.)

Technical Fundamentals

• Requirements management. (The failure to completely identify, fully develop, or properly manage project requirements is the single most cited reason for project failure. Requirements management includes determining exactly what the customer wants and then managing any changes that occur during the life of the project.)

• Design. (Too often the coding begins before there is a design. System design, like planning, is an activity in which discernible progress is difficult to show. Consequently, the tendency is to rush into metal bending and software coding because these are the activities that, on the surface at least, demonstrate progress. On the contrary, inadequate design always increases the schedule.)

• Construction. (System construction techniques designed to improve schedules should include testing at key points. The most effective software development projects tend to be those in which the developers write test plans and run the tests as they are developing the code. This approach encourages testing in small increments that are easily and quickly corrected as defects are found, thus improving the overall development schedule.)

• Software configuration management. (One of the most critical, but poorly accomplished, functions in software development projects is managing configuration changes. Generally, we think of configuration changes in two different ways. First, configuration changes can be changes to the product as it is being designed or constructed— essentially changes to the scope or original concept. Second, configuration changes might mean different functionality for the same basic product. That is, the basic system might have a certain memory capacity and speed, but another customer might request the basic system functions but with a higher memory and speed capability. In any case, tracking, controlling, and managing changes to the system is required to optimize the schedule.)

Quality Assurance Fundamentals

• Error-prone modules. (These are modules that, because of poor design, inattention to code-writing fundamentals, or overly complex routines, have an inordinate amount of errors. Isolating these modules and quickly correcting them will improve the schedule and strengthen the overall design. Usually, the error-prone problem resembles the 80/20 rule, which states that 80 percent of the problems are caused by 20 percent of the modules.)

• Testing. (Quality assurance relies on testing and other forms of inspection to determine the viability of the design and development. Testing often throughout the development, construction, and implementation stages will result in fewer defects and faster convergence to product completion and customer acceptance.)

• Technical reviews. (These are reviews to determine how the overall project is progressing relative to the plan. They also track how individual tasks are progressing according to requirements and design. A balance must be struck between having technical reviews often enough to ensure product integrity and so often as to interfere with the project progress.)

• Quality design. (Designing quality into a system and not inspecting it is by now the mantra followed by all who strive for high-quality products. Traditional quality processes depended heavily on quality inspection of the finished product, which often led to scrapping parts and reworking the product, a practice that can increase schedule and costs. Designing quality into the product from the project start, on the other hand, substantially reduces the need for rework, and generally improves the finished product. An equally important consideration is simplicity. Software developers know the importance of simple designs and simple routines and how much they improve their schedules, not to mention frustration and stress levels. In general, the objective in coding and software development should always be to use the simplest approach, routine, or coding sequence that works and satisfies the requirement. Anything more raises the potential for errors or defects.)

Managing Risks to Avoid Catastrophic Setbacks

The importance of risk and risk management were discussed in detail in Chapter 7. However, it is worth restating. Risk management is a developmental strategy that protects the project, and the organization, from failure. If properly exercised, it also carries with it the collateral benefit of significantly improving the development schedule. When one considers how devastating an unplanned risk can be, it is a wonder that risk management is not the highest priority of every organization. Risk management is a process that has to be supported by senior management, documented and promulgated to everyone in the organization, and implemented without fail in every project. To do less is to invite failure.

One cannot plan for, or identify, all risks. As we have pointed out, there are simply some risks that are not known, nor can their impact to the project be anticipated. But the majority of risks can be anticipated and planned for with contingency plans and reserves, either in money or time. The other risks can be dealt with if they occur, provided the organization is oriented toward proactively meeting and dealing with them.

One key component of risk management that is often overlooked, even in reasonably astute organizations, is the identification of risk triggers. A risk trigger is an event or an indication that signals the likelihood that a risk event is about to occur. If the project team has identified triggers, they can then recognize the potential onset of the risk event before it happens, and they often are able to eliminate the risk.

The three components of a rapid development strategy discussed to this point are really nothing more than efficient development practices. In other words, they are practices that any good software development organization should already practice. However, even good development organizations need to reexamine their processes occasionally, make sure their procedures are current, and make sure that the project teams are practicing them. Improving on basic development practices will improve the developmental process, but adding practices that target schedule improvement directly will shorten the development schedule even more.

Applying Schedule-Oriented Practices

Indirectly attacking the schedule by avoiding classic mistakes, applying developmental strategies, and managing risks definitely shorten the development time, but the amount of improvement depends entirely upon the amount of process or procedural improvement needed. In other words, organizations that already practice efficient development and continually improve their procedures will not realize much, if any, improvement in the development schedule simply by fine-tuning their methods. However, there are other, more direct schedule-oriented practices that significantly improve development time, even for those already efficient organizations. These schedule-oriented practices do not, however, take the place of good, efficient development techniques; they are used to enhance them.

There are three basic categories of schedule-oriented practices: speed-oriented practices, risk oriented practices, and visibility-oriented practices. The first (speed-oriented) means exactly that—concentrating on those practices that directly increase the speed of development. The second category has to do with focusing on risk elimination to avoid any kind of delay that might impact the schedule. And the third category focuses on those practices that provide complete project visibility to the customer and other stakeholders, thus avoiding delays due to misunderstandings, misinterpretation, or miscommunication.

Speed-Oriented Practices

Speed-oriented practices are techniques that shorten the development schedule but generally add risk. These techniques add risk when they involve either accomplishing tasks in parallel that might otherwise be done serially, or they involve developing project requirements with the customer as the project progresses, or both. Conscientiously adding risk to a project is not necessarily bad, but it does require diligence, tracking, and a contingency plan.

An example of applying a speed technique is shown in Exhibits 10-1 and 10-2. Exhibit 10-1 shows a partial project following a typical waterfall development process, that is, the phases or tasks follow each other serially. Exhibit 10-2 shows the same project being expedited by overlapping the tasks. Beginning work on the next task before its predecessor is complete shortens the development schedule. However, by starting the next task, one has to make assumptions that may not be correct. Hence, an element of risk is interjected into the process. The less stable the requirements, the less such an approach should be used. Dealing with more assumptions only exacerbates the problem of undefined requirements.

Exhibit 10-1: Partial example of waterfall development.

Exhibit 10-2: Example of a modified waterfall development.

Scheduling Risk-Oriented Practices

In general, risks invariably affect the schedule. Some risk events affect the schedule more directly and with more force than others do. For instance, a project having tasks that require special skills represents a threat to the schedule, if the appropriate resources are not available when needed. So a risk-oriented strategy would be to determine what skills are needed and when they are needed, then arrange for the requisite resources—either by teaming with a specialty company, hiring consultants, or even opting for an alternative technical approach, thus avoiding the skill set crisis.

Risk-oriented practices have more to do with avoiding delays than speeding up an existing development process. But the more sensitive a project team and organization is to risk, the fewer riskrelated delays will occur, creating a faster and smoother development cycle.

Visibility-Oriented Practices

It is often the case that customers and other stakeholders delay projects when they try to satisfy their own needs, or requirements, for information or status. This situation is particularly prevalent in projects that are of strategic importance or that have critical impact on the future of the organization, such as a new product with the potential for creating a competitive or market edge. Applying practices that provide visibility into the project activities and project progress satisfies the customer's or stakeholders' needs. In addition, it improves the schedule by eliminating unplanned reviews and inquiries. It also provides the added benefit of securing customer and stakeholder support and help throughout the project life cycle.

It is not likely that you will employ one or the other of these three schedule-oriented practices. It is more likely that you will use a combination of the three, because focusing on only one practice (to the exclusion of the others) generally creates problems in the other two areas. For instance, concentrating on speed invariably introduces some risk. So an approach that increases development speed, introduces a moderate, but controllable, amount of risk, and actively includes stakeholders leads to a faster and smoother development schedule.