Which agile development model uses timeboxing as a key element

I M P L E M E N T A T I O N

his chapter discusses how organizations evaluate and select projects to undertake from the many available projects. Once a project has been selected, the project

manager plans the project. Project management involves selecting a project methodology, creating the project work plan, identifying project staffing requirements, and preparing to manage and control the project. These steps produce important project management deliv- erables, including the work plan, staffing plan, standards list, project charter, and risk assessment.

OBJECTIVES ■ Explain how projects are selected in some organizations. ■ Describe various approaches to the SDLC that can be used to structure a devel-

opment project. ■ Explain how to select a project methodology based on project characteristics. ■ Become familiar with project estimation. ■ Be able to create a project work plan. ■ Describe project staffing issues and concerns. ■ Describe and apply techniques to coordinate and manage the project. ■ Explain how to manage risk on the project.

CHAPTER OUTLINE

C H A P T E R 2

T

PROJECT SELECTION AND MANAGEMENT

Introduction Project Selection

Applying the Concept at Tune Source Creating the Project Plan

Project Methodology Options Selecting the Appropriate

Methodology Estimating the Project Time Frame Developing the Work Plan Staffing the Project Coordinating Project Activities

Managing and Controlling the Project Refining Estimates Managing Scope Timeboxing Managing Risk

Applying the Concepts at Tune Source Summary Appendix 2A—The Function Point

Approach Appendix 2B—Project Management

Tools: The Gantt Chart and PERT Chart

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 45

INTRODUCTION

Most IT departments face a demand for IT projects that far exceeds the depart- ment’s ability to supply them. In the past 10 years, business application growth has exploded, and chief information officers (CIOs) are challenged to select projects that will provide the highest possible return on IT investments while managing project risk. In a recent analysis, AMR Research Inc. found that 2% –15% of projects taken on by IT departments are not strategic to the business.1 In today’s globally competitive business environment, the corporate IT department needs to carefully prioritize, select, and manage its portfolio of development projects.

Historically, IT departments have tended to select projects by ad hoc methods: first-in, first-out; political clout; or the squeaky wheel getting the grease. In recent years, IT departments have collected project information and mapped the projects’ contributions to business goals, using a project portfolio perspective.2 Project port- folio management, a process of selecting, prioritizing, and monitoring project results, has become a critical success factor for IT departments facing too many potential projects with too few resources.3 Software for project portfolio management, such as Hewlett Packard’s Project and Portfolio Management, Primavera Systems’ ProSight, and open-source Project.net, has become a valuable tool for IT organizations.

Once selected, a systems development project undergoes a thorough process of project management, the process of planning and controlling the project within a spec- ified time frame, at minimum cost, with the desired outcomes.4 A project manager has the primary responsibility for managing the hundreds of tasks and roles that need to be carefully coordinated. Project management has evolved into an actual profession with many training options and professional certification (e.g., Project Management Pro- fessional, or PMP) available through the Project Management Institute (www.pmi.org). Dozens of software products are available to support project management activities.

Although training and software are available to help project managers, unrea- sonable demands set by project sponsors and business managers can make project management very difficult. Too often, the approach of the holiday season, the chance at winning a proposal with a low bid, or a funding opportunity pressures project managers to promise systems long before they are realistically able to deliver them. These overly optimistic timetables are thought to be one of the biggest problems that projects face; instead of pushing a project forward faster, they result in delays.

Thus, a critical success factor for project management is to start with a real- istic assessment of the work that needs to be accomplished and then manage the project according to the plan. This can be accomplished by carefully following the basic steps of project management as outlined in this chapter. First, the project man- ager chooses a system development methodology that fits the characteristics of the project. Based on the size of the system, estimates of a time frame are made. Then, a list of tasks to be performed is created that forms the basis of the project work plan. Staffing needs are determined, and the project manager sets in place mecha- nisms to coordinate the project team throughout the project. Finally, the project manager monitors the project and refines estimates as work proceeds.

46 C h a p t e r 2 Project Selection and Management

1 Tucci, Linda, “PPM Strategy a CIO’s Must-Have in Hard Times,” SearchCIO.com, March 5, 2008. 2 Ibid. 3 Tucci, Linda, “Project portfolio management takes flight at Sabre,” SearchCIO.com, November 28, 2007. 4 A good book on project management is by Robert K. Wysocki, Effective Project Management: Traditional, Adaptive, Extreme, 5th Ed., New York: John Wiley & Sons, 2009. Also, the Project Management Institute (www.pmi.org) and the Information Systems Special Interest Group of the Project Management Institute (www.pmi-issig.org) have valuable resources on project management in information systems.

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 46

PROJECT SELECTION

Many IT organizations tackle a number of important initiatives simultaneously. For example, new software applications may be under development; new business models may be under consideration; organizational structures may be revised; new technical infrastructures may be evaluated. Collectively, these endeavors are man- aged as a program by the IT steering committee. The steering committee must provide oversight and governance to the entire set of projects that are undertaken by the IT organization. The individual projects that are accepted by the steering committee are temporary endeavors undertaken to create a unique product or service.

Investments in information systems projects today are evaluated in the context of an entire portfolio of projects. Decision makers look beyond project cost and consider a project’s anticipated risks and returns in relation to other projects. Com- panies prioritize their business strategies and then assemble and assess project port- folios on the basis of how they meet those strategic needs.

The focus on a project’s contribution to an entire portfolio of projects rein- forces the need for the feasibility study as described in Chapter 1. The approval committee has the responsibility to evaluate not only the project’s costs and expected benefits, but also the technical and organizational risks associated with the project. The feasibility analysis is submitted back to the approval committee, along with an updated system request. Using this information, the approval committee can exam- ine the business need (found in the system request) and the project risks (described in the feasibility analysis).

Portfolio management takes into consideration the different kinds of projects that exist in an organization—large and small, high risk and low risk, strategic and tactical.

Project Selection 47

Information systems are at the core of Sabre Holdings Corporation. The Sabre reservation system is the booking system of choice for travel agencies world- wide. Sabre is also the parent company of Travelocity. com, the second largest online travel agency in the United States.

Like many companies, Sabre’s IT department strug- gles with many more project requests than it has resources to accomplish—as many as 1500 proposals for 600 funded projects annually. Because of the volatile, compet- itive nature of the travel industry, Sabre is especially chal- lenged to be certain that IT is doing the right projects under constantly changing conditions. While traditional project management techniques focus on getting individ- ual projects done, Sabre needs to be able to rapidly change the entire set of projects it’s working on as market conditions shift.

Project portfolio management software collects and manages information about all projects—those that are

underway and those that are awaiting approval. The soft- ware helps prioritize projects, allocate employees, moni- tor projects in real time, flag cost and time variances, measure the ROI, and help the IT department objectively measure the efficiency and efficacy of IT investments.

Primavera Systems’ PPM software has enabled Sabre Holdings to update its queue of projects regularly, and projects are now prioritized quarterly instead of annually. A study of users of Hewlett Packard’s PPM Cen- ter software found that in all cases, the investment in the software paid for itself in a year. Other findings were an average 30% increase in on-time projects, a 12% reduc- tion in budget variance, and a 30% reduction in the amount of time IT spent on project reporting.

Sources: Tucci, Linda, “Project portfolio management takes flight at Sabre,“ SearchCIO.com, November 28, 2007. Tucci, Linda, “PPM strategy a CIO’s must-have in hard times,” SearchCIO.com, March 5, 2008.

2-A PROJECT PORTFOLIO MANAGEMENT: AN ESSENTIAL TOOL FOR IT DEPARTMENTS I N A C T I O N

CONCEPTS

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 47

(See Figure 2-1 for different ways of classifying projects.) A good project portfolio will have the most appropriate mix of projects for the organization’s needs. The committee acts as a portfolio manager, with the goal of maximizing benefits versus costs and bal- ancing other important factors of the portfolio. For example, an organization may want to keep high-risk projects to a level less than 20% of its total project portfolio.

The approval committee must be selective about where to allocate resources, because the organization has limited funds. This involves trade-offs in which the organization must give up something in return for something else in order to keep its portfolio well balanced. If there are three potentially high-payoff projects, yet all have very high risk, then maybe only one of the projects will be selected. Also, there are times when a system at the project level makes good business sense, but it does not at the organization level. Thus, a project may show a very strong economic feasibility and support important business needs for a part of the company; how- ever, it is not selected. This could happen for many reasons—because there is no money in the budget for another system, the organization is about to go through some kind of change (e.g., a merger, an implementation of a company-wide system like an ERP), projects that meet the same business requirements already are under- way, or the system does not align well with current or future corporate strategy.

Applying the Concepts at Tune Source

The approval committee met and reviewed the Digital Music Download project along with two other projects—one that called for a new supply-chain portal and another that involved the enhancement of Tune Source’s data warehouse. Unfortunately, the budget would allow for only one project to be approved, so the committee carefully examined

48 C h a p t e r 2 Project Selection and Management

Size What is the size? How many people are needed to work on the project?

Cost How much will the project cost the organization? Purpose What is the purpose of the project? Is it meant to improve the

technical infrastructure? support a current business strategy? improve operations? demonstrate a new innovation?

Length How long will the project take before completion? How much time will go by before value is delivered to the business?

Risk How likely is it that the project will succeed or fail? Scope How much of the organization is affected by the system? a

department? a division? the entire corporation? Economic Value How much money does the organization expect to receive in

return for the amount the project costs?F I G U R E 2 - 1 Ways to Classify Projects

It seems hard to believe that an approval committee would not select a project that meets real business needs, has a high potential ROI, and has a positive feasibility analysis. Think of a company that you

have worked for or know about. Describe a scenario in which a project may be very attractive at the project level, but not at the organization level.

2-1 TO SELECT OR NOT TO SELECTY O U R T U R N

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 48

Project Selection 49

In April 1999, one of Capital Blue Cross’ health-care insurance plans had been in the field for three years, but hadn’t performed as well as expected. The ratio of premiums to claims payments wasn’t meeting historic norms. In order to revamp the product features or pricing to boost performance, the company needed to understand why it was underperforming. The stakehold- ers came to the discussion already knowing they needed better extraction and analysis of usage data in order to understand product shortcomings and recommend improvements.

After listening to input from the user teams, the stake- holders proposed three options. One was to persevere with the current manual method of pulling data from flat files via ad hoc reports and retyping it into spreadsheets.

The second option was to write a program to dynamically mine the needed data from Capital’s customer information control system (CICS). While the system was

processing claims, for instance, the program would pull out up-to-the-minute data at a given point in time for users to analyze.

The third alternative was to develop a decision- support system to allow users to make relational queries from a data mart containing a replication of the relevant claims and customer data.

Each of these alternatives was evaluated on cost, benefits, risks, and intangibles.

QUESTION: 1. What are three costs, benefits, risks, and intangibles

associated with each project? 2. Based on your answer to question 1, which project

would you choose?

Source: “Capital Blue Cross,” CIO Magazine, February 15, 2000, by Richard Pastore.

2-2 PROJECT SELECTIONY O U R T U R N

A CIO needs to have a global view when identifying and selecting projects for her organiza- tion. I would get lost in the trees if I were to manage on a project-by-project basis. Given this, I categorize my projects according to my three roles as a CIO, and the mix of my project portfolio changes depending on the current business environment.

My primary role is to keep the business running. That means every day when each person comes to work, they can perform his or her job efficiently. I measure this using various service level, cost, and productivity meas- ures. Projects that keep the business running could have a high priority if the business were in the middle of a merger, or a low priority if things were running smoothly, and it were “business as usual.”

My second role is to push innovation that creates value for the business. I manage this by looking at our lines of business and asking which lines of business cre- ate the most value for the company. These are the areas for which I should be providing the most value. For example, if we had a highly innovative marketing strat- egy, I would push for innovation there. If operations were running smoothly, I would push less for innovation in that area.

My third role is strategic, to look beyond today and find new opportunities for both IT and the business of providing energy. This may include investigating process systems, such as automated meter reading or looking into the possibilities of wireless technologies.

Lyn McDermid

2-B INTERVIEW WITH LYN MCDERMID, CIO, DOMINION VIRGINIA POWER I N A C T I O N

CONCEPTS

the costs, expected benefits, risks, and strategic alignment of all three projects. Cur- rently, top management is anxious to bring the digital music download capability to market in order to satisfy the demands of its existing customers and potentially expand its customer base. The Digital Music Download project is best aligned with that goal. Therefore, the committee decided to fund the Digital Music Download project.

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 49

50 C h a p t e r 2 Project Selection and Management

At Marriott, we don’t have IT projects— we have business initiatives and strategies that are enabled by IT. As a result the only time a traditional “IT project” occurs is when we have an infrastructure upgrade that will lower costs or leverage better function- ing technology. In this case, IT has to make a business case for the upgrade and prove its value to the company.

The way IT is involved in business projects in the organization is twofold. First, senior IT positions are filled by people with good business understanding. Second, these people are placed on key business committees and forums where the real business happens, such as finding ways to satisfy guests. Because IT has a seat at the table, we are able to spot opportunities to support business strategy. We look for ways in which IT can enable or bet- ter support business initiatives as they arise.

Therefore, business projects are proposed, and IT is one component of them. These projects are then eval- uated the same as any other business proposal, such as a new resort—by examining the return on investment and other financial measures.

At the organizational level, I think of projects as must-do’s, should-do’s, and nice-to-do’s. The “must-do’s” are required to achieve core business strategy, such as guest preference. The “should-do’s” help grow the busi- ness and enhance the functionality of the enterprise. These can be somewhat untested, but good drivers of growth. The “nice-to-do’s” are more experimental and look further out into the future.

The organization’s project portfolio should have a mix of all three kinds of projects, with a much greater pro- portion devoted to the “must-do’s.” Carl Wilson

2-C INTERVIEW WITH CARL WILSON, CIO, MARRIOTT CORPORATION I N A C T I O N

CONCEPTS

Hygeia Travel Health is a Toronto- based health insurance company whose clients are the insurers of foreign tourists to the United States and Canada. Its project selection process is relatively straightforward. The project evaluation committee, consisting of six senior executives, splits into two groups. One group includes the CIO, along with the heads of operations and research and development, and it analyzes the costs of every project. The other group consists of the two chief marketing officers and the head of business development, and they analyze the expected benefits. The groups are permanent, and to stay objective, they don’t discuss a project until both sides have evaluated it. The results are then shared, both on a spreadsheet and in conversation. Projects are then approved, passed over, or tabled for future consideration.

Last year, the marketing department proposed pur- chasing a claims database filled with detailed information on the costs of treating different conditions at different facil- ities. Hygeia was to use this information to estimate how much money insurance providers were likely to owe on a given claim if a patient was treated at a certain hospital as opposed to any other. For example, a 45-year-old man suf- fering a heart attack may accrue $5000 in treatment costs at hospital A, but only $4000 at hospital B. This information

would allow Hygeia to recommend the less expensive hospital to its customer. That would save the customer money and help differentiate Hygeia from its competitors.

The benefits team used the same three-meeting process to discuss all the possible benefits of implement- ing the claims database. Members of the team talked to customers and made a projection by using Hygeia’s past experience and expectations about future business trends. The verdict: The benefits team projected a rev- enue increase of $210,000. Client retention would rise by 2%, and overall, profits would increase by 0.25%.

The costs team, meanwhile, came up with large estimates: $250,000 annually to purchase the database and an additional $71,000 worth of internal time to make the information usable. Put it all together and it was a financial loss of $111,000 in the first year.

The project still could have been good for marketing— maybe even good enough to make the loss acceptable. But some of Hygeia’s clients were also in the claims infor- mation business and, therefore, potential competitors. This, combined with the financial loss, was enough to make the company reject the project.

Source: “Two Teams Are Better Than One,” CIO Magazine, July 15, 2001, by Ben Worthen.

2-D A PROJECT THAT DOES NOT GET SELECTED I N A C T I O N

CONCEPTS

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 50

CREATING THE PROJECT PLAN

Once the project is launched by being selected by the approval committee, it is time to carefully plan the project. The project manager will follow a set of project man- agement guidelines, sometimes referred to as the project management life cycle, as he or she organizes, guides, and directs the project from inception to completion. Generally speaking, the project management phases consist of initiation, planning, execution, control, and closure.

In large organizations or on large projects, the role of project manager is com- monly filled by a professional specialist in project management. In smaller organiza- tions or on smaller projects, the systems analyst may fill this role. The project manager must make a myriad of decisions regarding the project, including determining the best project methodology, developing a work plan for the project, determining a staffing plan, and establishing mechanisms to coordinate and control the project.

Project Methodology Options

As we discussed in Chapter 1, the Systems Development Life Cycle (SDLC) provides the foundation for the processes used to develop an information system. A method- ology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and deliverables). There are many different systems development methodologies, and they vary in terms of the progression that is followed through the phases of the SDLC. Some methodologies are formal standards used by government agencies, while others have been developed by consulting firms to sell to clients. Many organizations have their own internal methodologies that have been refined over the years, and they explain exactly how each phase of the SDLC is to be performed in that company. Here we will review several of the predominant methodologies that have evolved over time.

Waterfall Development With waterfall development, analysts and users proceed sequentially from one phase to the next. (See Figure 2-2.) The key deliverables for each phase are typically voluminous (often, hundreds of pages) and are presented

Creating the Project Plan 51

F I G U R E 2 - 2 Waterfall Development

System

Planning

Analysis

Design

Implementation

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 51

to the approval committee and project sponsor for approval as the project moves from phase to phase. Once the work produced in one phase is approved, the phase ends and the next phase begins. As the project progresses from phase to phase, it moves forward in the same manner as a waterfall. While it is possible to go backward through the phases (e.g., from design back to analysis), it is quite difficult. (Imagine yourself as a salmon trying to swim upstream in a waterfall).

Waterfall development methodologies have the advantages of identifying requirements long before programming begins and limiting changes to the require- ments as the project proceeds. The key disadvantages are that the design must be completely specified before programming begins, a long time elapses between the completion of the system proposal in the analysis phase and the delivery of system, and testing is treated almost as an afterthought in the implementation phase. In addi- tion, the deliverables are often a poor communication mechanism, so important requirements may be overlooked in the volumes of documentation. If the project team misses an important requirement, expensive post-implementation programming may be needed. Users may forget the original purpose of the system, since so much time has elapsed between the original idea and actual implementation. Also, in today’s dynamic business environment, a system that met the existing environmental condi- tions during the analysis phase may need considerable rework to match the environ- ment when it is implemented. This rework requires going back to the initial phase and making needed changes through each of the subsequent phases in turn.

52 C h a p t e r 2 Project Selection and Management

F I G U R E 2 - 3 Parallel Development

System

Planning

Analysis

Design

Implementation

Design

Implementation

Implementation

Design

Implementation

Design

Subproject 2

Subproject 1

Subproject 3

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 52

There are two important variants of waterfall development. The parallel devel- opment methodologies evolved to address the lengthy time frame of waterfall devel- opment. As shown in Figure 2-3, instead of doing the design and implementation in sequence, a general design for the whole system is performed. Then the project is divided into a series of subprojects that can be designed and implemented in parallel. Once all subprojects are complete, there is a final integration of the separate pieces, and the system is delivered.

Parallel development reduces the time required to deliver a system, so changes in the business environment are less likely to produce the need for rework. The approach still suffers from problems caused by voluminous deliverables. It also adds a new problem: If the subprojects are not completely independent, design decisions in one subproject may affect another, and at the project end, integrating the subprojects may be quite challenging.

The V-model is another variation of waterfall development that pays more explicit attention to testing. As shown in Figure 2-4, the development process pro- ceeds down the left-hand slope of the V, defining requirements and designing sys- tem components. At the base of the V, the code is written. On the upward-sloping right side of the model, testing of components, integration testing, and, finally, acceptance testing are performed. A key concept of this model is that as require- ments are specified and components designed, testing for those elements is also defined. In this manner, each level of testing is clearly linked to a part of the analy- sis or design phase, helping to ensure high quality and relevant testing and maxi- mize test effectiveness.

Creating the Project Plan 53

Design

Implementation (coding)

Acceptance test design

System test design

Integration test design

Unit test design

Unit testing

Integration testing

System testing

Acceptance testing

Analysis

F I G U R E 2 - 4 V-Model

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 53

The V-model is simple and straightforward and improves the overall quality of systems through its emphasis on early development of test plans. Testing focus and expertise is involved in the project earlier rather than later; plus, the testers gain knowledge of the project early. It still suffers from the rigidity of the waterfall development process, however, and is not always appropriate for the dynamic nature of the business environment.

Rapid Application Development (RAD)5 Rapid application development is a collec- tion of methodologies that emerged in response to the weaknesses of waterfall development and its variations. RAD incorporates special techniques and computer tools to speed up the analysis, design, and implementation phases in order to get some portion of the system developed quickly and into the hands of the users for evaluation and feedback. CASE (computer-aided software engineering) tools, JAD (joint application development) sessions, fourth-generation/visual programming languages (e.g., Visual Basic.NET), and code generators may all play a role in RAD. While RAD can improve the speed and quality of systems development, it may also introduce a problem in managing user expectations. As systems are devel- oped more quickly and users gain a better understanding of information technology, user expectations may dramatically increase and system requirements may expand during the project (sometimes known as scope creep or feature creep).

RAD may be conducted in a variety of ways. Iterative development breaks the overall project into a series of versions that are developed sequentially. The most impor- tant and fundamental requirements are bundled into the first version of the system. This version is developed quickly by a mini-waterfall process, and once implemented, the users can provide valuable feedback to be incorporated into the next version of the sys- tem. (See Figure 2-5.) Iterative development gets a preliminary version of the system to the users quickly so that business value is provided. Since users are working with the system, important additional requirements may be identified and incorporated into sub- sequent versions. The chief disadvantage of iterative development is that users begin to work with a system that is intentionally incomplete. Users must accept that only the most critical requirements of the system will be available in the early versions and must be patient with the repeated introduction of new system versions.

System prototyping performs the analysis, design, and implementation phases concurrently in order to quickly develop a simplified version of the proposed sys- tem and give it to the users for evaluation and feedback. (See Figure 2-6). The sys- tem prototype is a “quick and dirty” version of the system and provides minimal features. Following reaction and comments from the users, the developers reana- lyze, redesign, and reimplement a second prototype that corrects deficiencies and adds more features. This cycle continues until the analysts, users, and sponsor agree that the prototype provides enough functionality to be installed and used in the organization. System prototyping very quickly provides a system for users to eval- uate and reassures users that progress is being made. The approach is very useful when users have difficulty expressing requirements for the system. A disadvantage, however, is the lack of careful, methodical analysis prior to making design and implementation decisions. System prototypes may have some fundamental design limitations that are a direct result of an inadequate understanding of the system’s true requirements early in the project.

54 C h a p t e r 2 Project Selection and Management

5 One of the best RAD books is that by Steve McConnell, Rapid Development, Redmond, WA: Microsoft Press, 1996.

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 54

Creating the Project Plan 55

System version 1

Planning

Analysis

Analysis

Implementation

Design

Analysis

Implementation

Design

Analysis

Implementation

Design

System version 2

System version 3

F I G U R E 2 - 5 Iterative Development

System prototype

System

Planning

Analysis

Design

Implementation

Implementation

F I G U R E 2 - 6 System Prototyping

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 55

56 C h a p t e r 2 Project Selection and Management

F I G U R E 2 - 7 Throwaway Prototyping

Throwaway prototyping6 includes the development of prototypes, but uses the prototypes primarily to explore design alternatives rather than as the actual new system (as in system prototyping). As shown in Figure 2-7, throwaway prototyping has a fairly thorough analysis phase that is used to gather requirements and to develop ideas for the system concept. Many of the features suggested by the users may not be well understood, however, and there may be challenging technical issues to be solved. Each of these issues is examined by analyzing, designing, and building a design prototype. A design prototype is not intended to be a working system. It con- tains only enough detail to enable users to understand the issues under consideration.

For example, suppose that users are not completely clear on how an order entry system should work. The analyst team might build a series of HTML pages to be viewed on a Web browser to help the users visualize such a system. In this case, a series of mock-up screens appear to be a system, but they really do nothing. Or, suppose that the project team needs to develop a sophisticated graphics program in Java. The team could write a portion of the program with artificial data to ensure that they could create a full-blown program successfully.

A system that is developed by this type of methodology probably requires sev- eral design prototypes during the analysis and design phases. Each of the prototypes is used to minimize the risk associated with the system by confirming that important issues are understood before the real system is built. Once the issues are resolved, the project moves into design and implementation. At this point, the design proto- types are thrown away, which is an important difference between this approach and system prototyping, in which the prototypes evolve into the final system.

Throwaway prototyping balances the benefits of well-thought-out analysis and design phases with the advantages of using prototypes to refine key issues before a system is built. It may take longer to deliver the final system compared with

Design prototype

System

Analysis

Analysis

Design

Implementation

Planning

Implementation

Design

6 Our description of the throwaway prototyping is a modified version of the Spiral Development Model devel- oped by Barry Boehm, “A Spiral Model of Software Development and Enhancement,” Computer, May, 1988, 21(5):61–72.

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 56

system prototyping (because the prototypes do not become the final system), but the approach usually produces more stable and reliable systems.

Agile Development Agile development7 is a group of programming-centric method- ologies that focus on streamlining the SDLC. Much of the modeling and documen- tation overhead is eliminated; instead, face-to-face communication is preferred. A project emphasizes simple, iterative application development in which every itera- tion is a complete software project, including planning, requirements analysis, design, coding, testing, and documentation. (See Figure 2.8). Cycles are kept short (one to four weeks), and the development team focuses on adapting to the current business environment. There are several popular approaches to agile development, including extreme programming (XP)8, Scrum9, and dynamic systems development method (DSDM).10 Here, we briefly describe extreme programming.

Extreme programming11 emphasizes customer satisfaction and teamwork. Communication, simplicity, feedback, and courage are core values. Developers com- municate with customers and fellow programmers. Designs are kept simple and clean. Early and frequent testing provides feedback, and developers are able to courageously respond to changing requirements and technology. Project teams are kept small.

An XP project begins with user stories that describe what the system needs to do. Then, programmers code in small, simple modules and test to meet those needs. Users are required to be available to clear up questions and issues as they arise. Stan- dards are very important to minimize confusion, so XP teams use a common set of names, descriptions, and coding practices. XP projects deliver results sooner than even the RAD approaches, and they rarely get bogged down in gathering requirements for the system.

For small projects with highly motivated, cohesive, stable, and experienced teams, XP should work just fine. However, if the project is not small or the teams aren’t

Creating the Project Plan 57

7 For more information, see www.AgileAlliance.org. 8 For more information, see www.extremeprogramming.org. 9 For more information, see www.controlchaos.com. 10 For more information, see www.dsdm.com 11 For more information, see K. Beck, Extreme Programming Explained: Embrace Change, Reading, MA: Addison-Wesley, 2000, and M. Lippert, S. Roock, and H. Wolf, Extreme Programming in Action: Practical Experiences from Real World Projects, New York: John Wiley & Sons, 2002.

Implementation

Design

Analysis

System

Planning

F I G U R E 2 - 8 Extreme Programming

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 57

jelled,12 then the likelihood of success for the XP project is reduced. Consequently, the use of XP in combination with outside contractors produces a highly questionable out- come, since the outside contractors may never “jell” with insiders.13 XP requires a great deal of discipline to prevent projects from becoming unfocused and chaotic. Fur- thermore, it is recommended only for small groups of developers (not more than 10), and it is not advised for mission-critical applications. Since little analysis and design documentation is produced with XP, there is only code documentation; therefore, maintenance of large systems developed using XP may be impossible. Also, since mission-critical business information systems tend to exist for a long time, the utility of XP as a business information system development methodology is in doubt. Finally, the methodology requires considerable on-site user input, something that is frequently difficult to obtain.14

Agile versus Waterfall-Based Methodologies Agile development approaches have existed for over a decade. Agile development practices were created in part because of dissatisfaction with the sequential, inflexible structure of waterfall- based approaches. Presently, agile development has made inroads into software development organizations, and studies show an even split between agile and waterfall users.15 Many organizations are experimenting with agile even while continuing to employ traditional waterfall approaches (see Concepts in Action 2F).

58 C h a p t e r 2 Project Selection and Management

12 A “jelled team” is one that has low turnover, a strong sense of identity, a sense of eliteness, a feeling that they jointly own the product being developed, and enjoyment in working together. For more information regarding jelled teams, see T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams, New York: Dorsett House, 1987. 13 Considering the tendency for offshore outsourcing, this is a major obstacle for XP to overcome. For more information on offshore outsourcing, see P. Thibodeau, “ITAA panel debates outsourcing pros, cons,” Com- puterworld Morning Update, September 25, 2003; and S. W. Ambler, “Chicken Little Was Right,” Software Development, October 2003. 14 Many of the observations described here on the utility of XP as a development approach are based on con- versations with Brian Henderson-Sellers. 15 Jan Stafford, “Agile and waterfall neck and neck as business side fails to engage.” SearchSoftwareQuality.com, March 16, 2009.

Travelers Insurance Company of Hartford, Connecticut has adopted agile development methodologies. The insurance field can be competitive, and Travelers wanted to have the shortest “time to implement” in the field. Travelers set up development teams of six people—two systems analysts, two repre- sentatives from the user group (such as claim services), a project manager, and a clerical support person. In the agile approach, the users are physically assigned to the development team for the project. While at first it might seem that the users are just sitting around drinking cof- fee and not doing their regular jobs, that is not the case. The rapport that is developed within the team allows for

instant communication. The interaction is very deep and profound. The resulting software product is delivered quickly—and, generally, with all the features and nuances that the users wanted.

QUESTIONS: 1. Could this be done differently, such as through JAD

sessions or having the users review the program on a weekly basis, rather than taking the users away from their real jobs to work on development?

2. What mind-set does an analyst need to work on such an approach?

2-E AGILE DEVELOPMENT AT TRAVELERS I N A C T I O N

CONCEPTS

c02ProjectSelectionAndManagement.qxd 9/22/11 10:46 AM Page 58

In fact, suggesting that an organization must be “all agile” or “all waterfall” is a false choice. Many software developers are actively seeking to integrate the best elements of both waterfall and agile into their software development practices. Hybrid agile-waterfall approaches are evolving. The process of developing information systems is never static. Most IS departments and project managers recognize that the choice of the “best” development methodology depends on project characteristics, as we discuss in the next section.

Selecting the Appropriate Development Methodology

As the previous section shows, there are many methodologies. The first challenge faced by project managers is to select which methodology to use. Choosing a methodology is not simple, because no one methodology is always best. (If it were, we’d simply use it everywhere!) Many organizations have standards and policies to guide the choice of methodology. You will find that organizations range from hav- ing one “approved” methodology to having several methodology options to having no formal policies at all.

Figure 2-9 summarizes some important methodology selection criteria. One important item not discussed in this figure is the degree of experience of the analyst team. Many of the RAD and agile development methodologies require the use of new tools and techniques that have a significant learning curve. Often, these tools and tech- niques increase the complexity of the project and require extra time for learning. Once they are adopted and the team becomes experienced, the tools and techniques can sig- nificantly increase the speed in which the methodology can deliver a final system.

Clarity of User Requirements When the user requirements for what the system should do are unclear, it is difficult to understand them by talking about them and explaining them with written reports. Users normally need to interact with tech- nology to really understand what the new system can do and how to best apply it to their needs. System prototyping and throwaway prototyping are usually more appropriate when user requirements are unclear, because they provide prototypes for users to interact with early in the SDLC. Agile development may also be appro- priate if on-site user input is available.

Creating the Project Plan 59

with unclear user requirements Poor Poor Poor Good Excellent Excellent Excellent

with unfamiliar technology Poor Poor Poor Good Poor Excellent Poor

that are complex Good Good Good Good Poor Excellent Poor

that are reliable Good Good Excellent Good Poor Excellent Good

with short time schedule Poor Good Poor Excellent Excellent Good Excellent

with schedule visibility Poor Poor Poor Excellent Excellent Good Good

Usefulness in Developing System Throwaway Agile Systems Waterfall Parallel V-Model Iterative Prototyping Prototyping Development

F I G U R E 2 - 9 Criteria for Selecting a Methodology

c02ProjectSelectionAndManagement.qxd 11/3/11 7:54 AM Page 59

Familiarity with Technology When the system will use new technology with which the analysts and programmers are not familiar (e.g., the first Web development pro- ject with Ajax), applying the new technology early in the methodology will improve the chance of success. If the system is designed without some familiarity with the base technology, risks increase because the tools may not be capable of doing what is needed. Throwaway prototyping is particularly appropriate for situations where there is a lack of familiarity with technology, because it explicitly encourages the developers to create design prototypes for areas with high risks. Iterative develop- ment is good as well, because opportunities are created to investigate the technol- ogy in some depth before the design is complete. While one might think that system prototyping would also be appropriate, it is much less so because the early proto- types that are built usually only scratch the surface of the new technology. Typically, it is only after several prototypes and several months that the developers discover weaknesses or problems in the new technology.

System Complexity Complex systems require careful and detailed analysis and design. Throwaway prototyping is particularly well suited to such detailed analysis and design, but system prototyping is not. The waterfall methodologies can handle complex systems, but without the ability to get the system or prototypes into users’ hands early on, some key issues may be overlooked. Although iterative develop- ment methodologies enable users to interact with the system early in the process, we have observed that project teams who follow these methodologies tend to devote less attention to the analysis of the complete problem domain than they might if they were using other methodologies.

System Reliability System reliability is usually an important factor in system development. After all, who wants an unreliable system? However, reliability is just one factor among several. For some applications, reliability is truly critical (e.g., medical equipment, missile control systems), while for other applications it is merely important (e.g., games, Internet video). The V-model is useful when relia- bility is important, due to its emphasis on testing. Throwaway prototyping is most appropriate when system reliability is a high priority, because detailed analysis and design phases are combined with the ability for the project team to test many dif- ferent approaches through design prototypes before completing the design. System prototyping is generally not a good choice when reliability is critical, due to the lack of careful analysis and design phases that are essential to dependable systems.

60 C h a p t e r 2 Project Selection and Management

Suppose that you are an analyst for the ABC Company, a large consulting firm with offices around the world. The company wants to build a new knowledge management system that can identify and track the expertise of individual consultants anywhere in the world on the basis of their education and the various consulting projects on which they have worked. Assume that this is a new idea that has never before been

attempted in ABC or elsewhere. ABC has an interna- tional network, but the offices in each country may use somewhat different hardware and software. ABC man- agement wants the system up and running within a year.

QUESTION: What methodology would you recommend that ABC

Company use? Why?

2-3 SELECTING A METHODOLOGYY O U R T U R N

c02ProjectSelectionAndManagement.qxd 9/22/11 7:55 AM Page 60

Short Time Schedules Projects that have short time schedules are well suited for RAD methodologies because those methodologies are designed to increase the speed of development. Iterative development and system prototyping are excellent choices when time lines are short because they best enable the project team to adjust the functionality in the system on the basis of a specific delivery date. If the project schedule starts to slip, it can be readjusted by removal of the functionality from the version or prototype under development. Waterfall-based methodologies are the worst choice when time is at a premium, because they do not allow for easy schedule changes.

Schedule Visibility One of the greatest challenges in systems development is know- ing whether a project is on schedule. This is particularly true of the waterfall-based methodologies because design and implementation occur at the end of the project. The RAD methodologies move many of the critical design decisions to a position earlier in the project to help project managers recognize and address risk factors and keep expectations in check.

Estimating the Project Time Frame

As the previous section illustrated, some development methodologies have evolved in an attempt to accelerate the project through the SDLC as rapidly as possible while still producing a quality system. Regardless of whether time is a critical issue on a project or not, the project manager will have to develop a preliminary estimate of the amount of time the project will take. Estimation16 is the process of assigning projected values for time and effort.

Creating the Project Plan 61

British Airways experienced prob- lems in software development despite a willing and capa- ble development team. Mike Croucher, brought in as chief software engineer, recommended a move to agile development after studying BA’s development process. The movement to agile was carefully conducted, recog- nizing that agile represents a huge cultural shift for the developers. BA development team members who were amenable to and suitable for agile methods were trained as agile mentors and coaches to help ease the transition.

Converting to agile methods enabled BA to substan- tially shorten the time requirements of certain projects. In some cases, a project that might have taken nine months

following a traditional methodology was completed in eight weeks. Only about 25% of the organization has changed to agile, however. BA recognized a continuing role for the waterfall methodology in certain areas of the organization and does not intend to force-fit agile every- where. At BA, agile is used when the user base is requiring speed, flexibility, and customer-oriented design. Agile is ideal when an area requiring small functionality can be developed and deployed earlier, according to Croucher.

Source: Mondelo, Daniel J. “Where agile development works and where it doesn’t: A user story.” SearchSoftwareQuality.com. February 24, 2010.

2-F WHERE AGILE WORKS AND DOESN’T WORK I N A C T I O N

CONCEPTS

16 Good books for further reading on software estimation are T. Capers Jones, Estimation Software Costs, New York: McGraw Hill, 1989; Coombs, IT Project Estimation: A Practical Guide to the Costing of Software, Cambridge University Press, 2003; and Steve McConnell, Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.

c02ProjectSelectionAndManagement.qxd 9/22/11 10:48 AM Page 61

Estimation can be performed manually or with the help of an estimation soft- ware package like Construx Estimate,TM Costar,TM or KnowledgePLAN®—there are over 50 available on the market. The estimates developed at the start of a pro- ject are usually based on a range of possible values (e.g., the design phase will take three to four months) and gradually become more specific as the project moves for- ward (e.g., the design phase will be completed on March 22).