-A framework for deciding how to pick the right methodology
Dr. Bjarne Berg
Table of Content
Introduction......
Background
Historical Perspective of Four Different Approaches
A. Joint Application Design......
B. Rapid Application Development......
C. System Development Life Cycle Methodologies......
D. Extreme Programming......
Proposed framework
Limitations, Assumptions and Risks
Conclusions
Works Cited
Introduction
One of the fists steps in developing a custom information technology system is to gather the right requirements. This is often done in a variety of ways based on the methodology that the company employs. This paper explores some of the methods and approaches to gather business requirements from a current and historical perspective. It also proposes a framework for deciding which method to employ under various conditions.
Background
Gathering business requirements is a complex process and involves a period of discovery and education, as well as formal communication, reviews and final approvals.There are many ways to accomplish these objectives and several approaches have been proposed over the years. Currently, the most common methodologies are the Rapid Application Development (RAD), the Joint Application Design (JAD), a collection of methodologies known as the System Development Life-Cycle (SDLC) methodologies named as a group after the approach they are based, as well as the newly formed Extreme Programming (XP) that became formalized over the last decade.
While these methods proposeunique ways to achieve the same objective, they all rely on the same criteria for achieving the final outcomes; the need for accurate business requirements. It is also important to note that most successful information technology implementations are based on meetingmultiple defined business requirements. This means that there is not a simple “one right requirement”, but a series of requirements that must be met. Unfortunately many of these requirements can also be mutually exclusive or simply contradictory. Therefore, an information technology implementation does not simply involve a series of black-and-white technical decisions; just because something is technically feasible does not mean it is wise or desirable from a business perspective. The core issue of a successfulimplementation is to strike a balance of what is technically feasible, within the resource framework of the project, and what the users expects from a functional standpoint. Information system managers musttherefore first bring a strategic perspective to the project by offering insight into potential technologies. The tactical aspects of the project can then be presented to the project team, explored, discussed and decided upon.
Depending on the methodology employed, the focus on the requirements gathering varies. Most traditional methodologiesare based on the System development Life Cycle (SDLC) approach. Under this approach, the two key strategic tasks are to completely define applications in the context of business requirements and to select technology based on compatibility and organizational know-how.Under the SDLC methodologies, defining an enterprise's requirements as completelyas possible is extremely important, because even modest changes in the applications' functions is assumed to cause dramatically changes to the resulting tactical choices.For a SDLC methodology, the longer the project duration, the more important the methodology is to keep the project on-track.
Another issue is the execution of the requirements gathering. Under all methodologies, the business requirement analyst is responsible for collecting, interviewing/meeting and consolidating business requirements from the business organization. The analyst must then present the findings in a way that is useful to the project team, and in a way that can be agreed to by the project sponsor. As a result, the business analyst must also have solid “diplomacy” skills.
Normally the role of a business analyst is performed by an individual who is familiar with the company’s line of business, or business processes. Typical skill requirements also include excellent interviewing skills, good at consolidating and prioritizing information, highly organized and detail oriented, ability to recognize other opportunities, and the to be able to manage expectations as part of the interview process (Berg, 1997).
Before we propose a new framework, let us review the history and purposes of the four core methodologies used today.
Historical Perspective of Four Different Approaches
A. Joint Application Design
In the late 1970s as a result of these complaints, the first versions of Joint Application Design (JAD) were developed by IBM. The methodology development team consisted of two key individuals, Tony Crawford of Canadaand Chuck Morris of North Carolina. The first success of this method was in Canada, where the developers ofthe JAD approach conducted a set of classes and seminars. With Tony Crawford as the “evangelist” of JAD it was soon adopted by many companies and organizations. However, thefirst use of JAD was limited to the areas of user requirements gathering and sometimes designs of the applications as well(Soltys & Crawford, 1997). The JAD workshop approach to obtaining the requirements was an alternative to the structured interviews that the SDLC methodologies advocated.
The following narrative illustrate the SDLC challenges of obtaining system requirements; “In most organizations, the systems development life cycle begins with the identification of a need, assignment of a project leader and team, and often the selection of a catchy acronym for the project. The leader pursues a series of separate meetings with the people who will use the system or be affected by it …… when it becomes apparent that the requirements from, say Accounting, don’t mesh with what the Sales department wants, the leader calls Sales and finds out the contact there is in the field and will not be back until tomorrow. Next day the leader reaches Sales, gets the information, calls accounting, and of course the person in Accounting is now out of the office, and so on. When everyone is finally in agreement, alas, the leader discovers that even more people should have been consulted because their needs require something entirely different. In the end, everyone is reluctant to "sign off" on the specifications. Other times, signing off comes easily. But when the system is delivered, it often has little to do with what the users really need” (Wood & Silver, 1995). "A user sign off is a powerless piece of paper" when matched against the fury of top management (Wetherbe, 1991).
JAD did not initially extend into the construction phase and the implementation phase of the project. Mr. Crawford first advocated that JAD was a set of workshops and not a comprehensive methodology. The core challenge that JAD was addressing was the merging of business knowledge with information technology design, to provide useful interaction and thereby improve the quality of the systems being developed. However, other companies soon adopted JAD and tailored it to their needs. A concept called JRP, or Joint Requirements Planning, is an approach to focus on the whole plan and execution of getting the “right” requirements. The JRP is often a supplement to the JAD sessions that is used for the specific program components and not a replacement for JAD (Yatco, 1999).
So, while JAD started a method for obtaining requirements only, JAD has evolved over time to become much broader. The University of Maine, as part of their GIS publications suggests using JAD as “one of the tools through out the system development process to keep the users involved all the time” and not merely as part of the requirements gathering phase where it started (Botkin, 1999). This view is reinforced by several universities that currently teach and advocates that JAD now covers a complete development life cycle of a system and is no longer just confined to the requirements gathering part of the project (The University of Texas, 2004). The term JAD is today being used so broadly that it has been described as a “joint venture among any people who need to make decisions affecting multiple areas of an organization”. In this case, JAD is defined as a structured workshop where people come together to plan projects, design systems, or make business decisions” (Daminen, et.al., 1999).
The proponents of JAD claims that the advantages of JAD include a dramatic shortening of the time it takes to complete a project. It also improves the quality of the final product by focusing on the up-front portion of the development lifecycle, thus reducing the likelihood of errors that are expensive to correct later on. The rational of JAD was that system development had some inherited laws of diminishing returns. The argument was that the traditional methods have several built-in delay factors that get worse as more people become involved. As a result, the traditional methods were not scalable to larger information technology projects (Wood & Silver, 1995). The guiding principles of a JAD sessions are:
- Keep it very focused
- Conducted in a dedicated environment
- Quickly drive major requirements and interface "look & feel"
JAD participants typically include:
- Facilitator – facilitates discussions, enforces rules
- End users – 3 to 5, attend all sessions
- Developers – 2 or 3, question for clarity
- Tie Breaker – Senior manager. Breaks end user ties, usually doesn’t attend
- Observers – 2 or 3, do not speak
- Subject Matter Experts – limited number for understanding business & technology
Today, JAD session is so all-encompassing that it covers all from simple work sessions to more advanced brainstorming session with tools and technology to capture ideas. JAD quickly became a tool for Business Process Re-engineering (BPR), information system architecture definition,business strategy planning,project management and data modeling (Jennerich, 1990). In the 1990s, iteven evolved into group dynamics and team formation theory including concepts such as "storming, norming, forming and performing" and has also evolved into conflict management (Soltys & Crawford, 1999).
As technology became more available, the JAD session also often became virtual. When JAD first was adapted as a methodology, a major benefit was proclaimed to be the unity of the team effort. However, as JAD gain adaptation in the 1990s many started to cut the cost of the sessions by reducing the travel expenses (Journal of Systems Management, 1995). It is also becoming very common to employ distributed prototype teams that were enabled by computer-supported cooperative work (Nobuhiro et. Al., 1998).It is important to note that the distribution of the team and the reduced interaction was for many the reason why JAD became less popular as a methodology in the lat 1990s and is today rather uncommon as the sole development approach. It did however, lay the framework for other more radical approaches such as Rapid Application Development (RAD) and Extreme Programming (XP).
B. Rapid Application Development
As JAD got established as a formal methodology, many critics of the SDLC methodologies had started various approaches to using Computer Aided Software engineering (CASE) tools to do interactive prototyping with the users. (Soltys & Crawford, 1999). An early critic of the traditional System Development Life Cycle Methodologies was Barry Boehm. As the leading software development manager at TRW, a credit management company, he early introduced a technique he called the “SpiralModel”. This model was an approach to software development that was not driven by typical programming, but instead by the risk of the project. He therefore believed that correct approach should be focusing on process modeling instead of phases as proposed in the SDLC methods. A core proposition to reduce the risk of the projects was to rely heavily on prototyping (Boehn, 1986).
The development approach of Bohem’s methodology was to separate the final deliverable into critical parts and performing a risk assessment of each of these parts. This was to be followed by prototyping for high risk areas as a way to drive the requirements and refine the final deliverables in an interactive way to the user community (Boehm, 1988). The heavy use of prototyping already had a strong following. In the late 1970s a development method known as the Evolutionary Life Cycle (ELC) had been developed by Tom Gilb. Under this approach there were no formal phase of a project, but each parts of the project was developed together with the users through interactive sessions where prototypes were demonstrated and feedback was sought (Gilb, XXXX).
Both of these methods were considered so complimentary that a logical framework had to be established to integrate these approaches in a formal manner. This framework methodology soon became known as the Rapid Iterative Production Prototyping (RIPP). The core user of this methodology and a driving force of the method was software development work done at DuPont in the 1980s. The RIPP soon was needed to be integrated into the most prevailing SDLC methods that were employed in the software industry and in most corporations. An early advocate of this merging of best of features from the RIPP and the SLDC methods was James Martin. Over time, he merged these approaches and proposed the first definition RAD as “a development lifecycle designed to give much faster development and higher-quality results than those achieved with the traditional lifecycle. It is designed to take the maximum advantage of powerful developmentsoftware that has evolved recently.” (Martin, 1990). In general, RAD compresses the phases of a SDLC methodology and introduces an interactive approach for each of these phases. It also combines the design and construction stages into a single phase where the development process is interactive and not sequential.
The core benefit is the time-to-delivery of the system. However, advocates of RAD also claims improved user satisfaction and less risk to the overall information system development effort. This is very important attributes. According to The Gartner Group, an influential think-tank for strategy and information technology, most organizations are faced with a large backlog of new systems to be developed.Over 65% of the typical budget is spent on the maintenanceof existing systems. These systems have little documentation and were developedwith programming languages and database systems that are difficult and timeconsuming to change. These organizations are thus faced with upgrading their agingsystems or building new applications. Traditional development lifecycles, however, are too slow and rigid to meet the business demands of today’s economy. A newmethodology must be implemented, one that allows organizations to build softwareapplications faster, better, and cheaper. RAD enables such development.
Alternative, but similar definitions to those introduced above have been proposed by Dr. Kettemborough. He broaden the definition to defined RAD as “an approach to building computer systems which combines Computer-Assisted Software Engineering (CASE) tools and techniques, user-driven prototyping, and stringent project delivery time limits into a potent, tested, reliable formula for top-notch quality and productivity. RAD drastically raises the quality of finished systems while reducing the time it takes to build them.” (Kettemborough,1999).
In addition to RAD’s reliance on prototyping, the characteristic of RAD is its abbreviated analysis stage where meetings are executed in short succession to get the requirements and where the design and construction stages of the project are combined. It also typically involves extensive early prototyping and tends to be used for smaller and stand alone system that require less integration into other larger environments (University of California at Davis, 1996). In general, applications that uses RAD tends to be characterized by the few interfaces that are build to maintain the application in a larger system landscape.
The critical method of RAD business requirements gathering is the initial information requirement gathering sessions. Typical ways to conduct these sessions is a one or two days meeting with uninterrupted time where lunch is provided on-site. Normally mobile phones, PDA and pagers are not allowed. The audience for these sessions is typically power users, casual users, people who today interact with the current system and managers who have a stake in the outcome of the information system development. A rapid pace is kept in these meetings and the number of attendees is kept at a manageable level, with typically no more than twenty people in attendance. The coordinators and business analysts will focus on shared information needs and conduct multiple sessions if needed. A guiding principle is that the meeting should not be trapped in details, since people are given a chance to provide feedback in writing for follow-up sessions with individuals.
The RAD initial information gathering sessions typically employs instruments such as a simple form called "information request form" and use it to gather the core relevant information about each report, processes and information availability being requested by the business community. This instrument is used to initially documentrequirements in a standardized format, prioritize the requirements, consolidate requirements and for follow-up discussions and reviews. Companies that use RAD as a development method often post such a form on the intranet and thereby give stakeholdersan easy way to communicate with the project team.A similar approach is often also used for security requirements and for dispositioning the requirement. Not all requirements may belong in the information system, and it is important that the developers do not use the system as a "dumping group". The project management and the business analysts are charged with making cost effective decisions. In general, the project team is responsible for making conscious decisions on what to include in the system and how to delivery the solution. However, without strong “guiding principles” there is a significant risk that the development designs and the system architecture becomes evolutionary and therefore has a high cost of ownership. The benefits of RAD are many. Beyond those mentioned earlier, advocates of RAD claims increased user involvement, less disruption to the business, more likely to avoid individual opinions and get more group consensus on system requirements, and the ability to use the RAD sessions as an information sharing and education event for the user community.