Development Methodology—Selection and Utilization

Using Development Methodologies
In this chapter, we explore various development methodologies used on projects either alone or in conjunction with a bigger project framework. Most project work can be a chaotic activity, often characterized by the phrase "fighting fires." The project is often started without much of an underlying plan, and the designs are often changed because of technology or error. Sometimes the project is simply cobbled together from multiple quick-paced decisions. This can be effective if the project is small, but as the project grows to be a medium- or super-sized project, it becomes increasingly difficult to add features to the system. The project manager's coordination skills are tested to the fullest extent as the project gets larger. Furthermore, mistakes become increasingly prevalent and difficult to fix (i.e., change control, issue logs). For example, building a space vessel begins with a blueprint based on numerous aeronautical and mathematical calculations, including material specifications, variables, and tolerances. Any change to this blueprint, which must be followed at all times, can kill the project because changes are costly and schedules can be horribly affected. The tools and materials that were manufactured specifically for the space vessel project are very expensive and should not change during the construction phase. On such a project, everything needs to be predictable.

Alternatively, when we look at developing software, we see something very different. We obviously try to build new software solutions—usually with new technologies—therefore, the associated risks are very high. In comparison to building space vessels, developing software is not the same. One is predictable and the other is not. In this chapter, we look at predictable methodologies, then at nonpredictable ones.
How Many Development Methodologies are There?
There are no one-size-fits-all development methodologies. Some companies have their own unique customized methodology for developing products or services; others simply use standard commercial off-the-shelf methodologies. With the incorrect methodology, discovering, designing, building, testing, and deploying projects can be chaotic. At least 20 different methodologies are competing to be the best methodology, and this list of methodologies keeps on growing (see Figure 4.1).


Figure 4.1: Assessing project development methodologies.
The project methodology that is chosen represents merely the framework for the real work to be done and indicates where creativity is needed. Many times, project managers simply select the available methodology and continue to develop their projects with that same methodology. When unpredictable results occur on a project, they raise issues and risks and try to manage reactively. Project managers often lack the controls to measure and respond to the unpredictable. Therefore, they must first determine that the methodology is the correct one.

Many project managers find it difficult to give up control as provided in traditional development. There is no guarantee that the team will deliver if you just follow a chosen methodology. Clients seldom complete requirement specifications because their requirements are constantly changing. The most logical solution is to simply evolve the product as the client's needs change along the project development process. This shows the need for a methodology more flexible than a formal waterfall approach. In fact, the trend is shifting to the more iterative or incremental style of methodologies.

Most project developments are wrongly approached with the assumption that the methodology used is well understood, and the project can be easily planned and estimated. When a project begins to fail, the development process is immediately provided with more resources and attention to get it back on track. Thus, cost and schedule overruns start occurring. These step-by-step approaches do not work because they do not cope with human and technical unpredictability. Rigid processes are often too constraining and fall short of delivering a project to operations or production.

Influence of New Product Development
In today's progressive marketplace, every moment counts. Companies developing new products, whether new bridge construction or a wireless mobile device, usually do so concurrently with existing product developments, often competing for similar resources and delivery dates. These projects must be developed in a synchronized approach with some differentiator toward the development of new stellar products. Hence, a competitive project methodology is needed that can show value and reflect the corporate strategy goals and objectives. The project team, armed with the right tools, techniques, and methodology, can keep the client involved and improve the bottom line. The methodology can be adjusted to fit the solution. The Standish Group's landmark 2000 report, "Chaos in the New Millennium," reports that outright project failures declined from 40 percent to 23 percent during the past five years but challenged projects swelled from 33 percent to 49 percent in the same period. Reasons listed included cost overruns and projects with lower functionality than promised. The correct choice of methodology plays an important part in elevating the rate of failures (see Figure 4.2).


Figure 4.2: New product development process.
Requirements for Selecting a Methodology
Table 4.1 illustrates essential decisions a project manager must make when selecting a methodology:

Budget. Budgets play a big role in any project, and the type of methodology to be used is key. For example, you have been given a mandate to develop a product within eight months. Your sponsor says, "Money is no problem; we need this product by the end of the year." If you select a heavy methodology, you may not achieve your goal because you will see the results only near the end of the project. (Earned value could possibly help, too.) A light, agile methodology may be the more appropriate choice because many of the lightweight methodologies are done in iterations and budgeted accordingly. If the project appears to be failing, funding is discontinued; if the iteration proves successful, funding for the next release is approved and work continues.

Team size. Methodologies are directly proportional to the team size—use light methodologies for smaller teams and heavy methodologies for larger teams. Projects with teams of 100 members geographically dispersed throughout the globe will not work using a small, lightweight methodology. The lines of communication grow more complex with the increase in team size, necessitating a more disciplined, coordinated model. For example, the Boston Big Dig project, the largest underground artery roadwork project in U.S. history—estimated at $14.5 billion for 7.5 miles of highway—requires thousands of workers across many vendors and employment agencies. A lightweight methodology is not suited to such a project.

Technology used. The technology used on a project affects the direction and type of methodology selected. Unfamiliar technology slows progress. On many projects today, simulation and testing of new technologies is actually considered a phase of the methodology.

Tools and techniques. Some project methodologies require more tools and techniques than others—for example, databases, visual modeling tools, and project management tools; some require hardly anything. If a project manager must manage multiple design changes, he or she will need a configuration management tool and technique.

Project criticality. Any critical project with a "must-deliver" target date needs to have the correct choice of methodology. The project might require additional resources to finish by the required date. If the methodology is too small, the project manager loses control; too large and formal, he or she slows the project down. A project manager's experience and skills will help in choosing the best approach.

Existing processes. In any company, the maturity and ease of use of existing project processes largely influence the methodology. Some company processes may be totally unreliable and ad hoc, slowing down completion of tasks. For example, you follow the standard internal purchasing process, which has a lead time of two months to receive goods. This process requires intervention or change.

Table 4.1: Requirements for selecting a methodology Requirement
Rationale

Budget
Methodologies require money and effects schedule.

Team size
Number of staff to be managed is required.

Project criticality
The urgency of the project decides the methodology.

Technology used
Hardware such as computer servers, composite materials, or electronics may be needed.

Documentation
The methodology needs documentation.

Training
Effective training to key support staff and project managers is required.

Best practices/lessons learned
Past lessons learned and good practices should be available.

Tools and techniques
Tools and techniques must be available.

Examination of existing processes
The maturity of existing processes will influence the pace at which a project will progress.

Software
Methodologies require software as part of their design.


No two methodologies are ever quite the same. At last count, my research on this topic found 45 different methodologies. If you don't have any methodologies in place in your company, on your next project, begin documenting issues and steps. Each major event (e.g., design) symbolizes either an end to a phase or the beginning of the next phase. All phases have unique activities and deliverables from previous activities. Before moving to the next phase, make sure all the activities and deliverables are completed. If you don't, expect to have more problems than usual.
Understanding Light and Heavy Methodologies
The choice between using a light or heavy methodology determines the success of the project.

Light Methodologies
Ever-increasing technological complexities, project delays, and changing client requirements brought about a small revolution in the world of development methodologies. A totally new breed of methodology—which is agile, adaptive, and involves the client every part of the way—is starting to emerge. Many of the heavyweight methodologists were resistant to the introduction of these "lightweight" or "agile methodologies" (Fowler 2001). These methodologies use an informal communication style. Unlike heavyweight methodologies, lightweight projects have only a few rules, practices, and documents. Projects are designed and built on face-to-face discussions, meetings, and the flow of information to the clients. The immediate difference of using light methodologies is that they are much less document-oriented, usually emphasizing a smaller amount of documentation for the project. For example, they are somewhat code-oriented: The team considers the source code as the project documentation. Advantages of a lightweight methodology include:

It works well with change.

It is people-oriented rather than process-oriented. It works with people rather than against them.

The methodology is complemented by the use of dynamic checklists.

If a client constantly introduces frequent changes to the design to see what the solution will look like—possibly to see immediate results or functionality of the product—a light methodology may be the suitable route to follow. Although you might set some limits to prevent too many changes, in today's ever-changing technological environment, clients might prefer that the project proceed in smaller iterations. The great thing about light methodologies is that they are learning methodologies. After each build or iteration, the team learns to correct issues on the project and improvement cycles form throughout the project. Additionally, with light methodologies, the project teams are smaller and rely on working more closely, fostering knowledge sharing, and having almost instantaneous feedback. The project manager does not need to develop heavy project documentation, but should instead focus on the absolute necessary documentation (i.e., project schedule).

Heavy Methodologies
The traditional project methodologies (i.e., SDLC approach) are considered bureaucratic or "predictive" in nature and have resulted in many unsuccessful projects. These heavy methodologies are becoming less popular. These methodologies are so laborious that the whole pace of design, development, and deployment actually slows down—and nothing gets done. Project managers tend to predict every project milestone because they want to foresee every technical detail (i.e., software code or engineering detail). This leads managers to start demanding many types of specifications, plans, reports, checkpoints, and schedules. Heavy methodologies attempt to plan a large part of a project in great detail over a long span of time. This works well until things start changing, and project managers inherently try to resist change.

If the project manager does not obtain a complete list of user requirements from clients for the heavyweight project, it's very likely that the heavy methodology will not work effectively because the project will be racked with change, slippages, and rework on the project documentation. A heavyweight methodology works on the assumption that the more rules and coordination there are, the better the project result will be. A complex project requires sufficient documentation just to jog the memory of the many team members on the project. However, excess methodology is very costly and inept—there are more updates to reports, plans, and schedules. Alternatively, there are times when a heavyweight methodology may be appropriate for super projects where it is necessary to gain stricter control and coordination between phases, and to improve the lines of communication between team members.

Any project with a team larger than 10 to 20 people who work in multiple locations may be a good candidate for a heavyweight methodology. Many companies are simply rushing to try to come up with the biggest and best methodology—including the most templates. Many, expecting miraculous results, become disappointed after a few months of actual project work. Because technologies are becoming more complex and integrated—facing many design and development problems—heavyweight methodologies can sometimes be the best choice, especially when multiple teams are working at different locations and when tighter control and formalization of key parts of the project is necessary.
Demystifying Iterative Development
Project managers or developers often confuse the meaning or use of the terms incremental, evolutionary, or iterative. Incremental, iterative, and evolutionary development are in fact the same thing. They execute all project phases (i.e., design, build) more than once. Whereas linear development (i.e., SDLC) is not. On any project, team members must understand the difference in these terms because they can define the future course of the methodology being selected or proposed on the next project. Iterative development adds agility to your project. For example, if you start a project and the executive sponsor informs you to follow an iterative approach, would you know what the sponsor meant? The following analogy best describes the differences in terminology:

Iterative. When building a house, the first iteration of the house is torn down, redesigned, and the second iteration is built from scratch. The emphasis is on re-doing the project. In the construction industry, this can be impractical and expensive; but in the information technology industry, this approach is common.

Incremental. When building a house, we start off with a basic design, and then incrementally add more rooms to the house. The emphasis is on adding to the project or expanding it. In addition, incremental models are best used to do a phased delivery to clients (e.g., release 1, release 2). This approach is more orientated to formal projects such as construction projects; information technology projects also use this approach as a dynamic way of delivering projects to clients.

The main difference between the iterative and incremental approaches is that you can still live with the incrementally built house, but the iterative house that has been torn down needs rebuilding.

Benefits of Iterative Development
The iterative development methodology provides the following benefits:

It encourages user feedback, which promotes obtaining real user requirements.

The system grows by adding new functions to each iteration.

Developers or planners start focusing on the biggest issues or risks facing the project.

Any misconceptions about design and requirements are identified upfront.

Everyone on the project has an accurate snapshot of the project status as it progresses.

Continual testing is carried out during the project.

The project workload is spread more evenly over the life cycle.

It allows for lessons learned on prior versions to be used in future releases.

The project or development manager divides the development/ design schedule into a few iterations (e.g., iterations 1, 2, 3, 4, 5, and 6). Each iteration is one to four weeks. The iterative approach now forms the basis for everything forward. Iterative approaches need to be managed slightly different from a normal project, as each iteration is built on its specific set of user requirements at that time. As iteration 1 is completed and reviewed with the project team and client, another iteration is planned wherein additional requirements and functionality are built into subsequent iterations. Each iteration concentrates on capturing the client's most pressing tasks. Instead of creating a detailed schedule, iterative methodology project planning should be more dynamic—each iteration is planned as it comes along, with smaller planning windows.
The Agile Methodologies
Project or development managers are still facing controversy between the agile and heavyweight methodologies. Currently, many companies favor the agile methodologies. Agile methodologies present new, nontraditional ways of building complex products and systems. Projects that use agile methodologies are now starting to report improved time line and cost savings, compared to those in the heavyweight family. Additionally, project teams are hailing the agile family of methodologies as remarkable because, at last, a series of methodologies contributes directly to the business. Many managers (i.e., functional, project, and development) tend to stick with the heavyweight methodology because they want to predict the entire project until the last man-hour, whereas the project teams (i.e., developers, coders, analysts) tend to stick with dynamic shorter cycles. Industries that use agile methodologies include financial, IT, telecom, utilities, and many more service industries. Furthermore, this trend is starting to emerge worldwide. The following are the most commonly used agile methodologies:

Extreme Programming (XP).

Scrum.

Crystal methodology.

Dynamic Systems Development Methodology (DSDM).

Rapid Application Development (RAD).

Adaptive software development.

Lean development.

Feature-driven development.

Agile methodologies better suit small projects where smaller project teams are involved. With larger team size and the complexity and duration of the project, the choice of a heavyweight methodology is purely from a command and control perspective. Many smaller companies do not use heavyweight methodologies and prefer the more agile approach to building solutions.

Extreme Programming (XP) Methodology
XP, one of the new promising breeds of lightweight methodologies, is the brainchild of Kent Beck. XP is one of the agile processes. It has received so much attention in recent years that some of the global project organizations are reviewing it for inclusion in their methodology portfolios. XP has few rules and a modest number of best practices, which are all relatively easy to use. It is based on iterations that embody several practices (like RUP), such as small releases, simple design, testing, and continuous integration. XP also promotes several effective techniques for the appropriate projects and circumstances; however, there are hidden assumptions, activities, and roles. XP teams use a simple form of planning and tracking to decide what should be done next and to predict when the project will be finished. XP embraces four core values that its project teams should follow: (1) communication, (2) feedback, (3) simplicity, and (4) courage.

The focus is on business value, where the team produces the software in a series of small, fully integrated releases that pass all the tests the client has defined. An XP project defines an integrated set of practices, which requires the full-time, on-site engagement, for such a project to work successfully. XP concentrates on construction of code—programming to meet a business need. How that business need occurs—and how it is modeled, captured, or reasoned—is not XP's primary concern. The XP phases are for planning purposes but the focus is on actually building the code. There is little emphasis on project documentation—XP is a clean and focused environment, which allows developers both creativity and freedom during development. The focus of XP is to reduce development costs. Although XP is worthy of consideration as a development methodology, it should not be used on large projects.

XP is a more constrained process that needs additions to make it fit a complete development project. For a small project team working in a relatively high-trust environment where the user is an integral part of the team, XP can work extremely well. Some of the most noteworthy XP practices are:

Refactoring. Restructure the system continually, without changing its behavior, to make it simpler or add flexibility. Determine if this is a good practice for the team. What is simple to one may be complex to another.

Testing. Developers continually write tests to go along with their code. The tests reflect the stories. XP urges you to write tests first, which is an excellent practice because it forces you to deeply understand the stories and then to ask more questions when necessary. Whether before or after code, you have to write them. Add them to your test suite and make sure to run them every time the code changes.

Pair programming. This technique ensures room for two developers to work effectively at a single workstation. This results in better code in less time, because developers can identify errors and possible faults in the software code (Strengthening the Case 2000).

Use CRC (class, responsibility, and collaboration) cards. This advocates that spending time to capture and maintain design documents is fundamental to a project's success. XP projects typically require a few hours to sketch the design or use CRC cards. The cards are used to teach users of XP the principles of object-orientated design.

XP can be used in conjunction with other development frameworks. XP has been successfully used with Rational Corporation's RUP. This combination has been called the dX process and is also RUP-compliant (Martin, nd).

The Scrum Methodology
In the agile community is a light methodology developed by Jeff Sutherland. The name Scrum comes from the game of rugby, played by two teams of 15 players with an oval ball. The ball is carried in the hand and may be passed backwards or laterally across the pitch or kicked in any direction. The opposing players attempt to halt the ball carrier by tackling him or her with their arms. Points are scored by:

Touching the ball down over the opponent's goal line (a try, worth 5 points).

Kicking the ball above the crossbar and between the uprights of a large H-shaped set of posts. This may be done either from a place kick following a rule infringement (a penalty goal) or a kick from the hand, provided the ball strikes the ground before being kicked (a drop goal). Both types are worth 3 points.

A conversion, which is attempted after a try has been scored and is similar to a penalty goal except worth only 2 points.

The purpose of the scrum is to restart play quickly, safely, and fairly after a minor infringement or stoppage. From a methodology perspective, Scrum refers to the mechanism used in rugby for getting an out-of-play ball back into play. Scrum is a lightweight, agile methodology focusing on software development. Scrum's two pillars are team empowerment and adaptability:

Team empowerment. When teams are given work to do, they are responsible for figuring out how to do it. The team does the best it can during each increment. While a team works, its only interaction with management is to tell management what is getting in the way and needs to be removed to improve productivity.

Adaptability. Scrum uses "punctuated equilibrium." The team maintains equilibrium during each increment, insulated from outside disturbance. Increments are punctuated every 30 days so that the team and management can evaluate what should be done during the next increment; this decision is based on what the team has accomplished and what the environment dictates is the next most important thing to do.

Scrum's ultimate goal is to deliver as much quality software as possible within a series (three to eight) of short time boxes (fixed-time intervals) called sprints that typically end every 30 days. Each stage in the development cycle (requirements, analysis, design, evolution, and delivery) is now mapped to this sprint(s). The traditional development stages are retained for convenience, primarily for tracking milestones. For example, the requirements stage may use one sprint including the delivery of a prototype. The analysis and design stages may take one sprint each while the evolution stage may take anywhere from three to five sprints. Defined and repeatable processes work only for tackling defined and repeatable problems with defined people in defined environments.

Before any sprint is started, you define the required functionality for that specific sprint and then allow the project team to develop and deliver it. At the end of every 30 days, the project manager inspects the results, assesses changes in the business environment, and empirically determines what to do next. The goal is to stabilize the requirements during the sprint. Each sprint operates on a number of work items called a backlog. As a rule, no more items are externally added into the backlog within a sprint. Internal items resulting from the original preallocated backlog can be added. The goal of a sprint is to complete as much quality software as possible but, typically in practice, less is delivered.

The project manager or executive does not leave the sprint after completion; he or she remains engaged throughout until all the sprints are finalized. The project team holds daily project meetings—called a Scrum—in which the team quickly runs through the activities for the following day. The following items typically arise from the scrum meetings:

Potential management blockages and problem areas.

Action items for management.

Overall status of completed items to date for the sprint cycle.

Each sprint takes a preallocated amount of work from the backlog. The team commits to it. As a rule, nothing is added externally during a sprint. External additions are made to the global backlog. Blocks resulting from the sprint can also be added to the backlog. A sprint ends with a demonstration of the new functionality. Scrum meetings typically take place at the same time and place every day; therefore, they serve to build a strong culture. As such, Scrum meetings are rituals that enhance the socialization of status, issues, and plans for the team. The scrum master leads the meetings and logs all the tasks from every member of the team into a global project backlog. Scrum meetings allow the development team to "socialize the team members' knowledge" and have a deep cultural transcendence. At the end of each sprint, there is a demonstration to:

Show the client what's going on.

Give the developer a sense of accomplishment.

Integrate and test a reasonable portion of the system being built.

Engage the team.

Ensure real progress—reduction of backlog, not just the generation of more documents.

After gathering and reprioritizing leftover and new tasks, a new backlog is formed and a new sprint starts. In contrast, Scrum allows us to build softer software, so there is no need to write full requirements up front. We should recognize that it is impossible to have full requirements specified upfront or to freeze the context and environment. Requirements are written in a context. Our system transforms that context. New problems arise in the system and the new context (see Figure 4.3).


Figure 4.3: Scrum methodology. Source: SCRUM, Adaptive Development Methodology, SCRUM © 2002. Used with permission of the Agile Community.
Scrum is a knowledge-creating process with a high level of information sharing during the whole cycle and work progress. The keys to Scrum are deciding the completion date for production or release, prioritizing functionality, identifying available resources, and making major decisions about architecture. Compared to more traditional methodologies, the planning phase is kept short because we know that events require changes to initial plans and methods. Scrum uses an empirical approach to development where interaction with the environment is not only allowed but also encouraged, thereby changing the scope. Table 4.2 provides a summary of the Scrum methodology.

Table 4.2: Scrum demystified Agile, lightweight process to manage and control development work.

A wrapper for existing engineering practices.

A team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing.

A process that controls the chaos of conflicting interests and needs.

A way to improve communications and maximize cooperation.

A way to maximize productivity.

Scalable from single projects to entire organizations.

A way to detect and cause the removal of anything that gets in the way of developing and delivering products.


Project management for a Scrum methodology involves a much greater focus on iteration and release management, error and fault resolution, and coaching the team to the next project release. Compared to traditional project management, we see that its sole focus is primarily on producing PERT charts, Network diagrams, status reports, and deliverables. The most immediate benefits of Scrum are shown in Table 4.3.

Table 4.3: Scrum benefits Increases user involvement in the development process.

Allows users to change and create requirements as the project progresses.

Ensures that the most important user functionality is built in first.

Always focuses on only the most important functionality.

Achieves new working functionality every 30 days.

Allows the user to choose the "build" or release at any time.

Eliminates the need for projects to be funded more than 30 days in advance.

Identifies something that can be done to improve productivity every single day.

Maximizes the ROI from the project.

Ensures that the team focuses on building only the functionality the user wants, eliminating additional functionality or cost.


Scrum is, therefore, based on empirical controls through inspection and adaptation. These controls are implemented through five basic practices:

Iterations. All work is done in short iterations, usually lasting 30 days. Inspections occur at the end of each iteration.

Increments. An increment of working functionality is produced at each iteration. At the end of each iteration, this increment is inspected.

Emergence. Complex systems emerge unpredictably across time. Their end state can be anticipated but not predicted. It is useless to try to predict their end states, and any such predictions can be misleading. Scrum deemphasizes traditional definitions of the requirements, architecture, and design of the system. These factors are allowed to emerge across time and have successfully done so on thousands of projects.

Self-organization. There are many unpredictable factors in IT development, ranging from technology to personnel. Given this unpredictability, it is important that management and teams are provided with the authority to plan and organize the work as they proceed, using their creativity and intellect to deal with the unexpected. They rely on their experience. They may also use any of the documented, defined development approaches (i.e., use case capturing, object modeling techniques) that they think will benefit the project.

Collaboration. The practice and working environments of agile methodologies work only if everyone collaborates freely and openly with one another. Techniques used here are (1) open working environments and (2) paired programming practices.

Crystal Methodologies
The Crystal methodology is a family of methodologies, which are all lightweight in nature and are segmented, as the name implies, into various color bands a crystal would emit (i.e., crystal clear, yellow, orange, maroon, blue, and violet). All Crystal methodologies are founded on a common value, "very strong on communication, they are human-centric, light on work products and are self-adapting" (Cockburn 2000). Methodology elements can be reduced to the extent that running software is delivered more frequently and interpersonal communication channels are richer. The human-centric approach really focuses on enhancing the work of the people involved on the project. Each member of the Crystal family or methodology addresses different project needs. The focuses of Crystal methodology are to (1) capture those components that make projects successful and (2) provide the project team with sufficient leverage and freedom to perform its work in a fun and creative manner. Additionally, smaller project teams develop better results because the communication is improved largely through close personal interaction and feedback between users, and the team is encouraged. Crystal does not encourage vast amounts of project documentation. Crystal captures the lessons learned from previous development projects, including the latest briefings on human thinking and communication, which is then reapplied to the development environment. The founder of the Crystal methodologies, Cockburn, states:

... Software development is a cooperative game, in which the participants help each other in reaching the end of the game—the delivery of software.... (p. 1)

When the project team starts developing the software, the team members immediately embark on describing their own development vocabulary in a manner that each project member understands. Two main principles of Crystal are:

Put people in the same location for improved development and creativity.

Encourage face-to-face communications.

Dynamic Systems Development Methodology (DSDM)
The DSDM, developed in the United Kingdom, is based on Rapid Application Development (RAD) that uses prototyping reiteration to deliver projects. This model has several aspects that differ from most common models. The difference is that time and resources are fixed and functionality of the deliverable is variable. In other models, the functionality (or product) is fixed, and resources and time are, to a certain extent, flexible.

Businesses today focus on finding the right solutions quickly. DSDM provides a project framework to make this objective achievable. DSDM's goal is speed—but not at the expense of quality. DSDM is independent, ensuring that it is adaptable to meet the needs of any organization. The simplicity, practicality, and flexibility of the approach are suitable for vendors, SMEs, consultants, and so on, making DSDM relevant across a variety of industries.

During the functional model iteration, first-pass descriptions of the new or changed processes are produced for refinement. A pilot project is developed during the design and build iteration. Throughout the development, feedback is used to evaluate and refine the processes so that they can be rolled out to the wider development population with confidence that they will achieve the benefits expected of them.

Implementation of processes involves significant communication and training of the project staff. Because communication is important throughout the development of improved processes and their final delivery, a communication strategy is added to the usual DSDM product set.

The structure of process improvement teams is described based on the DSDM roles and responsibilities. As always, the visionary role is an important one in keeping the focus of the work aligned to the needs of the organization.

Rapid Applications Development (RAD) Methodology
Sometimes users just want to see a product they can understand and not have to wait for the development to get off the build line. Traditional software development methodologies usually follow a sequence of steps with formal sign-offs normally at the end of each project phase. This sequence might be:

User requirements are gathered.

Specifications and the design are formulated.

Development begins and the project is completed.

Testing commences.

This process can be time consuming, but RAD shortens the approach.

But what happens if you discover during the development phase that the technology doesn't work? This has immense repercussions for the entire linear approach, and such a methodology could very well cause the project to fail. The time elapsed between the design and development could run into many months or man-hours. Clients are then often unwilling to take such a loss unless it is part of their key business strategy. Project managers need to employ a far more dynamic approach or project methodology for technologies that are untested or fall into a high-risk category. The RAD methodology may be the most suitable to realize immediate benefits.

Compared with many traditional methodologies, RAD compresses the analysis, design, development, and test phases into a dynamic series of short iterative development cycles. RAD uses shorter project phases, which means that benefits are realized much more quickly. With RAD, each iterative development cycle delivers a functional version of the proposed solution. The approach is almost cyclic in nature. However, many organizations don't have the time to spend lengthy periods on development; they want to see immediate results. By following a RAD methodology, clients are able to use a "building block approach" to see the results. Using RAD, results are almost immediate and the product starts becoming tangible. The developers have the advantage of building on their solution and gradually improving it until it reflects what the client requires. Some characteristics of the RAD methodology are:

Development teams are much smaller than normal.

The development team is integrated (i.e., analysts, developers, testers) and dedicated to the project.

The development phases are shorter, cyclical, and extremely dynamic.

Each release of a RAD version includes actual functionality the client needs.

Releases do not represent entire prototypes; rather, they are usable working systems.

Tasks and activities are performed concurrently rather than sequentially.

RAD makes use of changing technologies and quick decisions.

The entire approach is based on incremental changes, ultimately ending in a quality product.

The project team understands that frequent changes are part of the job.

See Figure 4.4 and Table 4.4 for examples of the RAD methodology.

Table 4.4: RAD methodology Category
Example

Data warehousing
SAP solution

Customer relationship management
Sales force automation (SFA) solution

Legacy applications conversion
Conversion of old mainframe systems to newer platforms

E-commerce applications
Web site development



Figure 4.4: RAD methodology.
Throughout a RAD methodology, it is important for the project manager to understand that a process needs to be followed. Key steps that need to be emphasized are:

Analysis. On RAD projects, it is crucial to interview all the various management staff in the client's organization (i.e., sales, marketing, legal, procurement, billing) for their requirements and objectives. These managers may see higher value in certain areas, and this needs to be captured in the user requirements statement (URS). (An electronic copy of the URS template is provided on the accompanying CD.)

Business model. When the analysis is completed, the task of putting together a business model is of the utmost importance. Here the project team relies on the analysts to formulate and create various options based on the client's intended strategy. This may include the types of reports needed, financial data, and even the workflow for the solution. (An electronic copy of this business case template is provided on the CD.)

Integration. Integration of RAD solutions into existing platforms and legacy systems is challenging; therefore, the RAD project team needs to work closely with the client's technical team to capture any business rules or integration issues that would contribute toward a successful integration of the new solution. The well-known software vendors have, to a great extent, already addressed integration into their software. However, if the required solution cannot integrate with certain systems, some customization and development may be needed. This is where the true nature of RAD reveals itself. It goes through various iterations and is repeated until the solution can integrate into the client's organization.

Documentation update. Because of the iterative nature of RAD, it is wise to maintain and update all project documentation on a regular basis as the versions are changed and new versions are tested. Proper configuration management of not only the project documentation, but also the source code and database instances, will keep the project under control.

RAD prototyping can reduce costs. It allows the project manager and the team to identify risks early during the project life cycle. The approach overlaps project phases. However, one of the biggest concerns found with RAD is with quality assurance during the development of the project. Project managers, therefore, must ensure that quality assurance is built into the project.