SYSTEMS ANALYSIS project

profiledaven9947
03_SystemsAnalysisDesignUML5thChapter2.pdf

I M P L E M E N TAT 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 Chapter 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 IN ACTION

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 Chapter 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?FIGURE 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 IN ACTION

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 Chapter 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 IN ACTION

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 IN ACTION

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

FIGURE 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 Chapter 2 Project Selection and Management

FIGURE 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 testingAnalysis

FIGURE 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 Chapter 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

FIGURE 2-5 Iterative Development

System prototype

System

Planning

Analysis

Design

Implementation

Implementation

FIGURE 2-6 System Prototyping

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

56 Chapter 2 Project Selection and Management

FIGURE 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

FIGURE 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 Chapter 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 IN ACTION

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

FIGURE 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 Chapter 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 IN ACTION

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).

The numbers used to calculate these estimates can come from several sources. They can be provided with the methodology that is used, taken from projects with similar tasks and technologies, or provided by experienced developers. Generally speaking, the numbers should be conservative. A good practice is to keep track of the actual time and effort values during the SDLC so that numbers can be refined along the way, and the next project can benefit from real data. One of the greatest strengths of systems consulting firms is the past experience that they offer to a pro- ject; they have estimates and methodologies that have been developed and honed over time and applied to hundreds of projects.

There are two basic ways to estimate the time required to build a system. The simplest method uses the amount of time spent in the planning phase to predict the time required for the entire project. The idea is that a simple project will require lit- tle planning, and a complex project will require more planning; so using the amount of time spent in the planning phase is a reasonable way to estimate overall project time requirements.

With this approach, you take the time spent in (or estimated for) the planning phase and use industry standard percentages (or percentages from the organization’s own experiences) to calculate estimates for the other SDLC phases. Industry stan- dards suggest that a “typical” business application system spends 15% of its effort in the planning phase, 20% in the analysis phase, 35% in the design phase, and 30% in the implementation phase. This would suggest that if a project takes four months in the planning phase, then the rest of the project likely will take a total of 22.66 person-months (4 !.15 " 22.66). These same industry percentages are then used to estimate the amount of time in each phase (Figure 2-10). The obvious limitation of this approach is that it can be difficult to take into account the specifics of your indi- vidual project, which may be simpler or more difficult than the “typical” project.

A more precise approach to estimation is called the function point approach. This approach is a more complex—and, it is hoped, more reliable—way of esti- mating time and effort for a project. The details of the function point approach are explained in Appendix 2A.

62 Chapter 2 Project Selection and Management

Typical industry 15% 20% 35% 30% standards for business applications

Estimates based Actual: Estimated: Estimated: Estimated: on actual figures 4 person- 5.33 person- 9.33 person- 8 person- for first stage months months months months of SDLC

SDLC = systems development life cycle.

Planning Analysis Design Implementation

FIGURE 2-10 Estimating Project Time Using Industry Standards

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

Developing the Work Plan

Once a project manager has a general idea of the size and approximate schedule for the project, he or she creates a work plan, which is a dynamic schedule that records and keeps track of all of the tasks that need to be accomplished over the course of the project. The project manager first must assemble important details about each task to be completed. Figure 2-11 shows the type of task information needed, including when it needs to be completed, the person assigned to do the work, and any deliverables that will result. The level of detail and the amount of information captured by the work plan depend on the needs of the project (and the detail usu- ally increases as the project progresses). Usually, the work plan is the main com- ponent of the project management software that we mentioned earlier.

To create a work plan, the project manager identifies the tasks that need to be accomplished and determines how long each one will take. Then the tasks are organized within a work breakdown structure.

Identify Tasks Remember that the overall objectives for the system were recorded on the system request, and the project manager’s job is to identify all the tasks that will be needed to accomplish those objectives. This is a daunting task, certainly. The methodology that was selected by the project manager should be a valuable resource, however. The methodology that seems most appropriate for the project provides a list of steps and deliverables.

A project manager can take the methodology, select the steps and deliverables that apply to the current project, and add them to the work plan. If an existing methodology is not available within the organization, methodologies can be pur- chased from consultants or vendors, or books like this textbook can serve as guid- ance. Using an existing methodology is the most popular way to create a work plan, because most organizations have a methodology that they use for projects.

If a project manager prefers to begin from scratch, he or she can use a structured, top-down approach whereby high-level tasks are defined first and then broken down into subtasks. Each step is then broken down in turn and num- bered in a hierarchical fashion. A list of tasks hierarchically numbered in this way is called a work breakdown structure, and it is the backbone of the project

Creating the Project Plan 63

Name of the task Perform economic feasibility Start date Jan 05, 2013 Completion date Jan 19, 2013 Person assigned to the task Project sponsor Mary Smith Deliverable(s) Cost–benefit analysis Completion status Complete Priority High Resources needed Spreadsheet software Estimated time 16 hours Actual time 14.5 hours

Task Information Example

FIGURE 2-11 Task Information

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

workplan. Figure 2-12 shows a portion of a work breakdown structure for the design phase of an actual data warehouse development project. Each of the main tasks focuses on one of the required design deliverables. Within each task, there are subtasks listed that detail the activities required to complete the main task.

The work breakdown structure can be organized in one of two ways: by SDLC phase or by product. For example, if a firm decided that it needed to develop a Web site, the firm could create a work breakdown structure based on the SDLC phases: planning, analysis, design, and implementation. In this case, a typical task that would take place during planning would be feasibility analysis. This task would be broken down into the different types of feasibility analysis: technical, economic, and organizational. Each of these would be further broken down into a series of subtasks. Alternatively, the firm could organize the work plan along the lines of the different products to be developed. In the case of a Web site, for example, the prod- ucts could include applets, application servers, database servers, the various sets of Web pages, a site map, and so on. Each of these products could be decomposed into the different tasks associated with the phases of the SDLC. With either approach, once the overall structure is determined, tasks are identified and included in the work breakdown structure of the work plan.

64 Chapter 2 Project Selection and Management

1 Design phase 30 Open 1.1 Develop database design document 9 Open

1.1.1 Staging database design 9 Open 1.1.2 Suspense database design 9 Open

1.2 Develop rejects-handling design document 9 1.1.1, 1.1.2 Open 1.2.1 Rejects-handling engine design 9 Open

1.3 Develop OLAP design document 9 1.1.1, 1.1.2 Open 1.3.1 Universe design 9 Open

1.4 Develop OLAP design part 1 8 Open 1.4.1 High-priority reports design 8 Open

1.5 Develop application design document 9 Open 1.5.1 Group consolidation and corporate reporting 9 Open

(GCCR) maintenance application design 1.6 Extract, transform, load (ETL) design document 2 Open

1.6.1 Data export utility design 2 Open 1.7 Application design document 25 Open

1.7.1 Web entry application UI design 25 Open 1.7.2 Web entry application UI design sign-off 1 Open 1.7.3 Web entry forms and database model validation 11 Open

1.8 Functional requirements document 9 Open 1.8.1 Application design 9 Open

1.8.1.1 User authentication 4 Open 1.8.1.2 Call logging 2 Open 1.8.1.3 Search 3 Open

(Thanks to Priya Padmanhabhan for suggesting this example.)

Task ID Task Name Duration (days) Dependency Status

FIGURE 2-12 Work Breakdown Structure

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

The number of tasks and level of detail depend on the complexity and size of the project. The larger the project, the more important it becomes to define tasks in detail so that essential steps are not overlooked.

The Project Work Plan The project work plan is the mechanism used to manage the tasks that are listed in the work breakdown structure. It is the project manager’s pri- mary tool for managing the project. Using it, the project manager can tell whether the project is ahead of or behind schedule, how well the project was estimated, and what changes need to be made to meet the project deadline.

Basically, the work plan is a table that lists all of the tasks in the work break- down structure, along with important task information such as the people who are assigned to perform the tasks, the actual hours that the tasks took, and the variances between estimated and actual completion times. (See Figure 2-13). At a minimum, the information should include the duration of the task, the current statuses of the tasks (i.e., open, complete), and the task dependencies, which occur when one task cannot be performed until another task is completed. For example, Figure 2-13 shows that task 1.2 and task 1.3 cannot begin until task 1.1 is completed. Key milestones, or important dates, are also identified on the work plan. Presentations to the approval committee, the start of end-user training, a company retreat, and the due date of the system prototype are the types of milestones that may be important to track.

STAFFING THE PROJECT

Staffing the project includes determining how many people should be assigned to the project, matching people’s skills with the needs of the project, motivating them to meet the project’s objectives, and minimizing project team conflict that will occur over time. The deliverable for this part of project management is a staffing plan, which describes the number and kinds of people who will work on the pro-ject, the overall reporting structure, and the project charter, which describes the project’s objectives and rules.

Staffing Plan

The first step to staffing is determining the average number of staff needed for the project. To calculate this figure, divide the total person-months of effort by the optimal schedule. So to complete a 40 person-month project in 10 months, a team should have an average of four full-time staff members, although this may change over time as different specialists enter and leave the team (e.g., business analysts, programmers, technical writers).

Many times, the temptation is to assign more staff to a project to shorten the project’s length, but this is not a wise move. Adding staff resources does not trans- late into increased productivity; staff size and productivity share a disproportionate relationship, mainly because a large number of staff members is more difficult to coordinate. The more a team grows, the more difficult it becomes to manage. Imagine how easy it is to work on a two-person project team: the team members share a single line of communication. But adding two people increases the number of com- munication lines to six, and greater increases lead to more dramatic gains in com- munication complexity. Figure 2-14 and Your Turn 2-4 illustrate the impact of adding team members to a project team.

One way to reduce efficiency losses on teams is to understand the complexity that is created in numbers and to build in a reporting structure that tempers its effects.

Staffing the Project 65

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

66

FI GU

RE 2

-1 3

Pro jec

t W ork

Pl an

1 De

sig n

Ph as

e 31

Fr

i Fr

i O

pe n

11 /1

6/ 13

12

/2 8/

13

1. 1

De ve

lo p

da ta

ba se

d es

ig n

M eg

an

9 M

on

Th ur

s O

pe n

do cu

m en

t 12

/3 /1

3 12

/1 3/

13

1. 1.

1 St

ag in

g da

ta ba

se d

es ig

n M

eg an

9

M on

Th

ur s

O pe

n 12

/3 /1

3 12

/1 3/

13

1. 1.

2 Su

sp en

se d

at ab

as e

M eg

an

9 M

on

Th ur

s O

pe n

de sig

n 12

/3 /1

3 12

/1 3/

13

1. 2

De ve

lo p

re je

ct s-h

an dl

in g

M eg

an

9 Fr

i W

ed

1. 1.

1, 1

.1 .2

O

pe n

de sig

n do

cu m

en t

12 /1

4/ 13

12

/2 6/

13

1. 2.

1 Re

je ct

s-h an

dl in

g en

gi ne

M

eg an

9

Fr i

Fr i

O pe

n de

sig n

12 /1

4/ 13

12

/2 6/

13

1. 3

De ve

lo p

O LA

P de

sig n

Jo ac

hi m

9

Fr i

W ed

1.

1. 1,

1 .1

.2

O pe

n do

cu m

en t

12 /1

4/ 13

12

/2 6/

13

1. 3.

1 Un

ive rse

d es

ig n

Jo ac

hi m

9

Fr i

W ed

O

pe n

12 /1

4/ 13

12

/2 6/

13

1. 4

De ve

lo p

O LA

P de

sig n

Ke vin

8

Fr i

Tu es

O

pe n

pa rt

1 12

/7 /1

3 12

/1 8/

13

1. 4.

1 H

ig h-p

rio rit

y re

po rts

Ke

vin

8 Fr

i Tu

es

O pe

n de

sig n

12 /7

/1 3

12 /1

8/ 13

1. 5

De ve

lo p

ap pl

ic at

io n

To m

as

9 Fr

i W

ed

O pe

n de

sig n

do cu

m en

t 12

/1 4/

13

12 /2

6/ 13

1. 5.

1 G

ro up

c on

so lid

at io

n To

m as

9

Fr i

W ed

O

pe n

an d

co rp

or at

e re

po rti

ng

12 /1

4/ 13

12

/2 6/

13 (G

C C

R) m

ai nt

en an

ce

ap pl

ic at

io n

de sig

n

Es tim

at ed

A

ct ua

l

D ur

at io

n St

ar t

Fi ni

sh

St ar

t Fi

ni sh

D

ur at

io n

D ep

en de

nc y

St at

us Ta

sk I

D

Ta sk

N am

e A

ss ig

ne d

To

(d ay

s)

D at

e D

at e

D at

e D

at e

va ri

an ce

(C on

tin ue

d)

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

67

FI GU

RE 2

-1 3

Pro jec

t W ork

Pl an

1. 6

Ex tra

ct , t

ra ns

fo rm

, l oa

d Jo

ac hi

m

2 Th

u Fr

i O

pe n

(E TL

) d es

ig n

do cu

m en

t 12

/2 7/

13

12 /2

8/ 13

1. 6.

1 Da

ta e

xp or

t u tili

ty de

sig n

Jo ac

hi m

2

Th u

Fr i

O pe

n 12

/2 7/

13

12 /2

8/ 13

1. 7

Ap pl

ic at

io n

de sig

n M

ei -lin

g 25

Fr

i Fr

i O

pe n

do cu

m en

t 11

/1 6/

13

12 /2

1/ 13

1. 7.

1 W

eb e

nt ry

a pp

lic at

io n

M ei

-lin g

25

Fr i

Fr i

O pe

n UI

d es

ig n

11 /1

6/ 13

12

/2 1/

13

1. 7.

2 W

eb e

nt ry

a pp

lic at

io n

M ei

-lin g

1 Fr

i Fr

i O

pe n

UI d

es ig

n sig

n-o ff

12 /3

0/ 13

12

/3 0/

13

1. 7.

3 W

eb e

nt ry

fo rm

s an

d Ke

vin

11

W ed

W

ed

O pe

n da

ta ba

se m

od el

va lid

at io

n 11

/2 1/

13

12 /5

/1 3

1. 8

Fu nc

tio na

l r eq

ui re

m en

ts C

ha nt

el le

9

M on

Th

u O

pe n

do cu

m en

t 12

/1 0/

13

12 /2

0/ 13

1. 8.

1 Ap

pl ic

at io

n de

sig n

C ha

nt el

le

9 M

on

Th u

O pe

n 12

/1 0/

13

12 /2

0/ 13

1. 8.

1. 1

Us er

a uth

en tic

at io

n C

ha nt

el le

4

M on

Th

u O

pe n

12 /1

0/ 13

12

/1 3/

13

1. 8.

1. 2

C al

l l og

gi ng

C

ha nt

el le

2

Fr i

M on

O

pe n

12 /1

4/ 13

12

/1 7/

13

1. 8.

1. 3

Se ar

ch

C ha

nt el

le

3 Tu

e Th

u O

pe n

12 /1

8/ 13

12

/2 0/

13

(T ha

nk s

to P

riy a

Pa dm

an ha

bh an

fo r s

ug ge

sti ng

th is

ex am

pl e.

)

Es tim

at ed

A

ct ua

l

D ur

at io

n St

ar t

Fi ni

sh

St ar

t Fi

ni sh

D

ur at

io n

D ep

en de

nc y

St at

us Ta

sk I

D

Ta sk

N am

e A

ss ig

ne d

To

(d ay

s)

D at

e D

at e

D at

e D

at e

Va ri

an ce

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

Two-person team Four-person team FIGURE 2-14 Increasing Complexity with Larger Teams

The rule of thumb is to keep team sizes under 8 to 10 people; therefore, if more peo- ple are needed, create subteams. In this way, the project manager can keep the com- munication effective within small teams, which in turn communicate to a contact at a higher level in the project.

After the project manager understands how many people are needed for the project, he or she creates a staffing plan that lists the roles that are required for the project and the proposed reporting structure for the project. Typically, a project will have one project manager who oversees the overall progress of the development effort, with the core of the team composed of the various types of analysts described in Chapter 1. A functional lead usually is assigned to manage a group of analysts, and a technical lead oversees the progress of a group of programmers and more technical staff members.

There are many structures for project teams; Figure 2-15 illustrates one pos- sible configuration of a project team. After the roles are defined and the structure is in place, the project manager needs to think about which people can fill each role. Often, one person fills more than one role on a project team.

When you make assignments, remember that people have technical skills and interpersonal skills, and both are important on a project. Technical skills are useful for working with technical tasks (e.g., programming in Java) and in trying to understand the various roles that technology plays in the particular project (e.g., how a Web server should be configured on the basis of a projected number of hits from customers).

Interpersonal skills, on the other hand, include interpersonal and communica- tion abilities that are used when dealing with business users, senior management

Figure 2-14 shows the increasing number of communication channels that exist as a team grows from two members to four members. Using the fig- ure as a guide, draw the number of communication chan- nels that will be needed in a six-member team. Now, determine the number of communication channels that will be needed in an eight-person team.

QUESTIONS: 1. How many communication channels are there in the

six-member team? The eight-member team? 2. From your results, how effective do you think a 12-

member team would be? A 16-member team?

2-4 COMMUNICATION COMPLEXITYY O U R T U R N

68 Chapter 2 Project Selection and Management

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

Staffing the Project 69

executives, and other members of the project team. They are particularly critical for performing the requirements-gathering activities and when addressing organiza- tional feasibility issues. Each project will require unique technical and interper- sonal skills. For example, a Web-based project may require Internet experience or Java programming knowledge, or a highly controversial project may need analysts who are particularly adept at managing political or volatile situations.

Ideally, project roles are filled with people who have the right skills for the job; however, the people who fit the roles best may not be available; they may be working on other projects, or they may not exist in the company. Therefore, assigning project team members really is a combination of finding people with the appropriate skill sets and finding people who are available. When the skills of the available project team members do not match those actually required by the project, the project manager has several options to improve the situation. First, people can be pulled off other projects, and resources can be shuffled around. This is the most disruptive approach from the organi- zation’s perspective. Another approach is to use outside help—such as a consultant or contractor—to train team members and start them off on the right foot. Training classes are usually available for both technical and interpersonal instruction, if time is available. Mentoring may also be an option; a project team member can be sent to work on another similar project so that he or she can return with skills to apply to the current job.

Motivation Assigning people to tasks isn’t enough; project managers need to moti- vate the people to make the project a success. Motivation has been found to be the number-one influence on people’s performance,17 but determining how to motivate the team can be quite difficult. You may think that good project managers motivate their staff by rewarding them with money and bonuses, but most project managers agree that this is the last thing that should be done. The more often you reward team members with money, the more they expect it—and most times monetary motiva- tion won’t work.

Assuming that team members are paid a fair salary, technical employees on project teams are much more motivated by recognition, achievement, the work

FIGURE 2-15 Possible Reporting Structure

Functional lead

Project manager

ProgrammerAnalyst Analyst Analyst Programmer

Technical lead

17 Barry W. Boehm, Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981. One of the best books on managing project teams is by Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams, New York: Dorset House, 1987.

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

itself, responsibility, advancement, and the chance to learn new skills.18 If you feel that you need to give some kind of reward for motivational purposes, try a pizza or free dinner, or even a kind letter or award. These often have much more effective results. Figure 2-16 lists some other motivational don’ts that you should avoid to ensure that motivation on the project is as high as possible.

Handling Conflict The third component of staffing is organizing the project to mini- mize conflict among group members. Group cohesiveness (the attraction that mem- bers feel to the group and to other members) contributes more to productivity than do project members’ individual capabilities or experiences.19 Clearly defining the roles on the project and holding team members accountable for their tasks is a good way to begin mitigating potential conflict on a project. Some project managers develop a project charter that lists the project’s norms and ground rules. For example, the charter may describe when the project team should be at work, when staff meetings will be held, how the group will communicate with each other, and the procedures for updating the work plan as tasks are completed. Figure 2-17 lists additional techniques that can be used at the start of a project to keep conflict to a minimum.

Coordinating Project Activities

Like all project management responsibilities, the act of coordinating project activ- ities continues throughout the entire project until a system is delivered to the project sponsor and end users. This step includes putting efficient development practices in

70 Chapter 2 Project Selection and Management

18 F. H. Hertzberg, “One More Time: How Do You Motivate Employees?” Harvard Business Review, 1968, January–February. 19B. Lakhanpal, “Understanding the Factors Influencing the Performance of Software Development Groups: An Exploratory Group-Level Analysis,” Information and Software Technology, 1993, 35(8):468–473.

Assign unrealistic deadlines Few people will work hard if they realize that a deadline is impossible to meet.

Ignore good efforts People will work harder if they feel that their work is appreciated. Often, all it takes is public praise for a job well done.

Create a low-quality product Few people can be proud of working on a project that is of low quality.

Give everyone on the project If everyone is given the same reward, then high-quality a raise people will believe that mediocrity is rewarded—and they

will resent it. Make an important decision Buy-in is very important. If the project manager needs to

without the team’s input make a decision that greatly affects the members of her team, she should involve them in the decision-making process.

Maintain poor working conditions A project team needs a good working environment, or motivation will go down the tubes. This includes lighting, desk space, technology, privacy from interruptions, and reference resources.

Source: Adapted from Rapid Development, Redmond, WA: Microsoft Press, 1996, by Steve McConnell.

Don’ts Reasons

FIGURE 2-16 Motivational Don’ts

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

• Clearly define plans for the project. • Make sure the team understands how the project is important to the organization. • Develop detailed operating procedures and communicate these to the team members. • Develop a project charter. • Develop schedule commitments ahead of time. • Forecast other priorities and their possible impact on project.

Source: H. J. Thamhain and D. L. Wilemon, “Conflict Management in Project Life Cycles,” Sloan Management Review, Spring 1975.

FIGURE 2-17 Conflict Avoidance Strategies

place and mitigating risk. These activities occur over the course of the entire SDLC, but it is at this point in the project that the project manager needs to put them in place. Ultimately, these activities ensure that the project stays on track and that the chance of failure is kept at a minimum. The rest of this section will describe each of these activities in more detail.

CASE Tools Computer-aided software engineering (CASE) is a category of software that automates all or part of the development process. Some CASE software packages are primarily used during the analysis phase to create integrated diagrams of the sys- tem and to store information regarding the system components (often called upper CASE), whereas others are design-phase tools that create the diagrams and then gen- erate code for database tables and system functionality (often called lower CASE). Integrated CASE, or I-CASE, contains functionality found in both upper-CASE and lower-CASE tools in that it supports tasks that happen throughout the SDLC. CASE comes in a wide assortment of flavors in terms of complexity and functionality, and there are many good programs available in the marketplace, such as the Visible Analyst Workbench, Oracle Designer, Rational Rose, and the Logic Works suite.

The benefits of using CASE are numerous. With CASE tools, tasks are much faster to complete and alter; development information is centralized; and informa- tion is illustrated through diagrams, which typically are easier to understand. Poten- tially, CASE can reduce maintenance costs, improve software quality, and enforce discipline; and some project teams even use CASE to assess the magnitude of changes to the project.

Of course, like anything else, CASE should not be considered a silver bullet for project development. The advanced CASE tools are complex applications that require significant training and experience to achieve real benefits. Often, CASE serves only as a glorified diagramming tool that supports the practices described in Chapter 5 (process modeling) and Chapter 6 (data modeling). Our experience has shown that CASE is a helpful way to support the communication and sharing of project diagrams and technical specifications—as long as it is used by trained developers who have applied CASE on past projects.

The central component of any CASE tool is the CASE repository, otherwise known as the information repository or data dictionary. The CASE repository stores the diagrams and other project information, such as screen and report designs, and it keeps track of how the diagrams fit together. For example, most CASE tools will warn you if you place a field on a screen design that doesn’t exist in your data model. As the project evolves, project team members perform their tasks by using CASE. As you read through the textbook, we will indicate when and how the CASE tool can be used so that you can see how CASE supports the project tasks.

Staffing the Project 71

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

Standards Members of a project team need to work together, and most project man- agement software and CASE tools provide access privileges to everyone working on the system. When people work together, however, things can get pretty confus- ing. To make matters worse, people sometimes get reassigned in the middle of a project. It is important that their project knowledge does not leave with them and that their replacements can get up to speed quickly.

Standards are created to ensure that team members are performing tasks in the same way and following the same procedures. Standards can range from formal rules for naming files to forms that must be completed when goals are reached to programming guidelines. See Figure 2-18 for some examples of the types of standards that a project may include. When a team forms standards and then follows them, the project can be completed faster because task coordina- tion becomes less complex.

Standards work best when they are created at the beginning of each major phase of the project and well communicated to the entire project team. As the team moves forward, new standards are added when necessary. Some standards (e.g., file-naming conventions, status reporting) are applied to the entire SDLC, whereas others (e.g., programming guidelines) are appropriate only for certain tasks.

Documentation Another technique that project teams put in place during the plan- ning phase is good documentation, which includes detailed information about the tasks of the SDLC. Often, the documentation is stored in project binder (s) that con- tain all the deliverables and all the internal communication that takes place—the history of the project.

A poor project management practice is permitting the project team to wait until the last minute to create documentation. This typically leads to an undocu- mented system that no one understands. In fact, many problems that companies had in updating their systems to handle the year-2000 crisis were the result of the lack of documentation. Good project teams learn to document the system’s history as it evolves, while the details are still fresh in their memory.

A simple way to set up your documentation is to get some binders and use dividers to separate content according to the major phases of the project. An addi- tional divider should contain internal communication, such as the minutes from status meetings, written standards, letters to and from the business users, and a dic- tionary of relevant business terms. Then, as the project moves forward, place the deliverables from each task into the project binder with descriptions so that some- one outside of the project will be able to understand it, and keep a table of contents up to date with the content that is added. Documentation takes time up front, but it is a good investment that will pay off in the long run.

72 Chapter 2 Project Selection and Management

Select a computer-aided software engineering (CASE) tool—either one that you will use for class, a program that you own, or a tool that you can examine over the Web. Create a list of the capabilities that are offered by the CASE tool.

QUESTION: Would you classify the CASE as upper CASE, lower

CASE, or integrated CASE (I-CASE)? Why?

2-5 COMPUTER-AIDED SOFTWARE ENGINEERING TOOL ANALYSISY O U R T U R N

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

MANAGING AND CONTROLLING THE PROJECT

The science (or art) of project management is in making trade-offs among three important concepts: the size of the system (in terms of what it does), the time to complete the project (when the project will be finished), and the cost of the project. Think of these three things as interdependent levers that the project manager con- trols throughout the SDLC. Whenever one lever is pulled, the other two levers are affected in some way. For example, if a project manager needs to readjust a dead- line to an earlier date, then the only solution is to decrease the size of the system (by eliminating some of its functions) or to increase costs by adding more people or having team members work overtime. Often, a project manager will have to work with the project sponsor to change the goals of the project, such as developing a system with less functionality or extending the deadline for the final system, so that the project has reasonable goals that can be met.

Therefore, in the beginning of the project, the manager needs to estimate each of these levers and then continuously assess how to roll out the project in a way that meets the organization’s needs.

Managing and Controlling the Project 73

Documentation standards The date and project name should appear as a header on all documentation.

All margins should be set to 1 inch. All deliverables should be added to the project binder and

recorded in its table of contents. Coding standards All modules of code should include a header that lists the

programmer, last date of update, and a short description of the purpose of the code.

Indentation should be used to indicate loops, if-then-else statements, and case statements.

On average, every program should include one line of comments for every five lines of code.

Procedural standards Record actual task progress in the work plan every Monday morning by 10 A.M.

Report to project update meeting on Fridays at 3:30 P.M. All changes to a requirements document must be approved by the project manager.

Specification requirement standards Name of program to be created Description of the program’s purpose Special calculations that need to be computed Business rules that must be incorporated into the program Pseudocode Due date

User interface design standards Labels will appear in boldface text, left-justified, and followed by a colon.

The tab order of the screen will move from top left to bottom right.

Accelerator keys will be provided for all updatable fields.

Types of Standards Examples

FIGURE 2-18 A Sampling of Project Standards

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

Once the project begins, the project manager monitors the progress of the team on the project tasks. As the project team members make periodic status reports, the project manager updates the project work plan. As discussed in Appen- dix 2B, the Gantt chart and PERT chart are valuable tools for the project manager to use to evaluate project progress and, if necessary, redirect resources. As the project proceeds, it may be necessary for the project manager to revise the original esti- mates made for the project. In addition, the manager must be on the watch for increases in project scope, which can make completing the project on time and under budget very difficult. Finally, the project manager should constantly assess the risk profile of the project and take steps to manage those risks.

Refining Estimates

The estimates that are produced during the planning phase will need to be refined as the project progresses. This does not necessarily mean that estimates were poorly done at the start of the project; it is virtually impossible to develop an exact assess- ment of the project’s schedule before the analysis and design phases are conducted. A project manager should expect to be satisfied with broad ranges of estimates that become more and more specific as the project’s product becomes better defined.

In the planning phase, when a system is first requested, the project sponsor and project manager attempt to predict how long the SDLC will take, how much it will cost, and what the system will ultimately do when it is delivered (i.e., its func- tionality). However, the estimates are based on very little knowledge of the system. As the project moves into the analysis phase, more information is gathered, the sys- tem concept is developed, and the estimates become even more accurate and pre- cise. As the system moves closer to completion, the accuracy and precision increase until the final system is delivered.

74 Chapter 2 Project Selection and Management

I was once on a project to develop a system that should have taken a year to build. Instead, the business need demanded that the system be ready within 5 months—impossible!

On the first day of the project, the project manager drew a triangle on a white board to illustrate some tradeoffs that he expected to occur over the course of the project. The corners of the triangle were labeled Func- tionality, Time, and Money. The manager explained, “We have too little time. We have an unlimited budget. We will not be measured by the bells and whistles that this system contains. So over the next several weeks, I want you as developers to keep this triangle in mind and do everything it takes to meet this 5-month deadline.”

At the end of the 5 months, the project was deliv- ered on time; however, the project was incredibly over

budget, and the final product was “thrown away” after it was used because it was unfit for regular usage. Remark- ably, the business users felt that the project was very suc- cessful because it met the very specific business needs for which it was built. They believed that the trade-offs that were made were worthwhile. Barbara Wixom QUESTIONS: 1. What are the risks in stressing only one corner of the

triangle? 2. How would you have managed this project? Can you

think of another approach that might have been more effective?

2-G TRADE-OFFS IN ACTION

CONCEPTS

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

According to one of the leading experts in software development,20 a well- done project plan (prepared at the end of the planning phase) has a 100% margin of error for project cost and a 25% margin of error for schedule time. In other words, if a carefully done project plan estimates that a project will cost $100,000 and take 20 weeks, the project will actually cost between $0 and $200,000 and take between 15 and 25 weeks. Figure 2-19 presents typical margins of error for other stages in the project. It is important to note that these margins of error apply only to well- done plans; a plan developed without much care has a much greater margin of error.

What happens if you overshoot an estimate (e.g., the analysis phase ends up lasting two weeks longer than expected)? There are a number of ways to adjust future estimates. If the project team finishes a step ahead of schedule, most project managers shift the deadlines sooner by the same amount but do not adjust the prom- ised completion date. The challenge, however, occurs when the project team is late in meeting a scheduled date. Three possible responses to missed schedule dates are presented in Figure 2-20. We recommend that if an estimate proves too optimistic early in the project, do not expect to make up for lost time—very few projects end up working this way. Instead, change your future estimates to include an increase similar to the one that was experienced. For example, if the first phase was com- pleted 10% over schedule, increase the rest of your estimates by 10%.

Managing Scope

You may assume that your project will be safe from scheduling problems because you carefully estimated and planned your project up front. However, the most com- mon reason for schedule and cost overruns occurs after the project is underway— scope creep.

Scope creep happens when new requirements are added to the project after the original project scope was defined and “frozen.” It can happen for many rea- sons: Users may suddenly understand the potential of the new system and realize new functionality that would be useful; developers may discover interesting capa- bilities to which they become very attached; a senior manager may decide to let this system support a new strategy that was developed at a recent board meeting.

Managing and Controlling the Project 75

20 Barry W. Boehm and colleagues, “Cost Models for Future Software Life Cycle Processes: COCOMO 2.0,” in J. D. Arthur and S. M. Henry (eds), Annals of Software Engineering: Special Volume on Software Process and Product Measurement, Amsterdam: J. C. Baltzer AG Science Publishers, 1995.

Planning phase System request 400 60 Project plan 100 25

Analysis phase System proposal 50 15 Design phase System specifications 25 10

Source: Barry W. Boehm and colleagues, “Cost Models for Future Software Life Cycle Processes: COCOMO 2.0,” in J. D. Arthur and S. M. Henry (eds.) Annals of Software Engineering Special Volume on Software Process and Product Measurement, Amsterdam: J. C. Baltzer AG Science Publishers, 1995.

Typical Margins of Error for Well-Done Estimates

Phase Deliverable Cost (%) Schedule Time (%)

FIGURE 2-19 Margins of Error in Cost and Time Estimates

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

Unfortunately, after the project begins, it becomes increasingly difficult to address changing requirements. The ramifications of change become more exten- sive, the focus is removed from original goals, and there is at least some impact on cost and schedule. Therefore, the project manager must actively work to keep the project tight and focused.

The keys are to identify the requirements as well as possible in the beginning of the project and to apply analysis techniques effectively. For example, if needs are fuzzy at the project’s onset, a combination of intensive meetings with the users and proto- typing could be used so that users “experience” the requirements and better visualize how the system could support their needs. In fact, the use of meetings and prototyping has been found to reduce scope creep to less than 5% on a typical project.

Of course, some requirements may be missed no matter what precautions you take, but several practices can help to control additions to the task list. First, the project manager should allow only absolutely necessary requirements to be added after the project begins. Even at that point, members of the project team should carefully assess the ramifications of the addition and present the assessment back to the users. For example, it may require two more person-months of work to cre- ate a newly defined report, which would throw off the entire project deadline by several weeks. Any change that is implemented should be carefully tracked so that an audit trail exists to measure the change’s impact.

Sometimes, changes cannot be incorporated into the present system even though they truly would be beneficial. In this case, these additions to scope should

76 Chapter 2 Project Selection and Management

Assumptions Actions Level of Risk

If you assume that the rest of the project is simpler than the part that was late and is also simpler than believed when the original schedule estimates were made, you can make up lost time.

Do not change schedule. High risk

If you assume that the rest of the project is simpler than the part that was late and is no more complex than the original estimate assumed, you can’t make up the lost time, but you will not lose time on the rest of the project.

Increase the entire schedule by the total amount of time that you are behind (e.g., if you missed the scheduled date by two weeks, move the rest of the schedule dates to two weeks later). If you included padded time at the end of the project in the original schedule, you may not have to change the promised system delivery date; you’ll just use up the padded time.

Moderate risk

If you assume that the rest of the project is as complex as the part that was late (your original estimates were too optimistic), then all the scheduled dates in the future underestimate the real time required by the same percentage as the part that was late.

Increase the entire schedule by the per- centage of weeks that you are behind (e.g., if you are two weeks late on part of the project that was supposed to take eight weeks, you need to increase all remaining time estimates by 25%). If this moves the new deliv- ery date beyond what is acceptable to the project sponsor, the scope of the project must be reduced.

Low risk

FIGURE 2-20 Possible Actions When a Schedule Date Is Missed

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

be recorded as future enhancements to the system. The project manager can offer to provide functionality in future releases of the system, thus getting around telling someone no.

Timeboxing

Up until now, we have described projects that are task oriented. In other words, we have described projects that have a schedule that is driven by the tasks that need to be accomplished, so the greater number of tasks and requirements, the longer the project will take. Some companies have little patience for development projects that take a long time, and these companies take a time-oriented approach that places meeting a deadline above delivering functionality.

Think about your use of word processing software. For 80% of the time, you probably use only 20% of the features, such as the spelling checker, boldfacing, and cutting and pasting. Other features, such as document merging and creation of mail- ing labels, may be nice to have, but they are not a part of your day-to-day needs. The same goes for other software applications; most users rely on only a small sub- set of their capabilities. Ironically, most developers agree that, typically, 75% of a system can be provided relatively quickly, with the remaining 25% of the function- ality demanding most of the time.

To resolve this incongruency, a technique called timeboxing has become quite popular, especially when rapid application development (RAD) methodologies are used. This technique sets a fixed deadline for a project and delivers the system by that deadline no matter what, even if functionality needs to be reduced. Time boxing ensures that project teams don’t get hung up on the final “finishing touches” that can drag out indefinitely, and it satisfies the business by providing a product within a relatively fast time frame.

There are several steps to implementing timeboxing on a project (Figure 2-21). First, set the date of delivery for the proposed goals. The deadline should not be impossible to meet, so it is best to let the project team determine a realistic due date. Next, build the core of the system to be delivered; you will find that time- boxing helps create a sense of urgency and helps keep the focus on the most important features. Because the schedule is absolutely fixed, functionality that cannot be completed needs to be postponed. It helps if the team prioritizes a list of features beforehand to keep track of what functionality the users absolutely need. Quality cannot be compromised, regardless of other constraints, so it is important that the time allocated to activities is not shortened unless the require- ments are changed (e.g., don’t reduce the time allocated to testing without reduc- ing features). At the end of the period, a high-quality system is delivered. Likely, future iterations will be needed to make changes and enhancements, and the timeboxing approach can be used once again.

Managing and Controlling the Project 77

1. Set the date for system delivery. 2. Prioritize the functionality that needs to be included in the system. 3. Build the core of the system (the functionality ranked as most important). 4. Postpone functionality that cannot be provided within the time frame. 5. Deliver the system with core functionality. 6. Repeat steps 3 through 5, to add refinements and enhancements.FIGURE 2-21

Steps for Timeboxing

c02ProjectSelectionAndManagement.qxd 11/3/11 7:31 AM Page 77

Managing Risk

One final facet of project management is risk management, the process of assess- ing and addressing the risks that are associated with developing a project. Many things can cause risks: weak personnel, scope creep, poor design, and overly opti- mistic estimates. The project team must be aware of potential risks so that problems can be avoided or controlled well ahead of time.

Typically, project teams create a risk assessment, or a document that tracks potential risks along with an evaluation of the likelihood of the risk and its potential impact on the project (Figure 2-22). A paragraph or two is included that explains potential ways that the risk can be addressed. There are many options: A risk could be publicized, avoided, or even eliminated by dealing with its root cause. For example, imagine that a project team plans to use new technology, but its members have identified a risk in the fact that its members do not have the right technical skills. They believe that tasks may take much longer to perform because of a high learning curve. One plan of attack could be to eliminate the root cause of the risk—the lack of technical experience by team members—by finding time and resources that are needed to provide proper training to the team.

78 Chapter 2 Project Selection and Management

System projects are notorious for being late and over budget. When should management stop a project that is late or costing more than the intended budget? Consider this case:

Valley Enterprises opted to implement Voice over Internet Protocol (VoIP) service in its Phoenix, Arizona, service area. The company has 15 locations in the Phoenix area, all with local area networks and all with secure Wi-Fi connections. The company’s current phone system was designed and implemented in the 1950s, when Valley operated in three locations. As more locations were added, standard telecommunications solutions were implemented, with little thought devoted to compat- ibility. Over the years, phone services were added as new buildings and facilities arose. Valley CEO Doug Wilson heard of VoIP at a trade show and contacted TMR Telecommunications Consultants, requesting a bid. TMR spent a week with the CIO of Valley Enterprises, gathering data, and submitted a bid for $50,000 in late 2007. The project was to be started by March 2008 and completed by January 2009. The bid was accepted.

TMR started the project in March 2008. In late July 2008, TMR was bought out by Advanced Communica-

tions of Scottsdale, Arizona. The merger delayed the project by over a month initially. In early September 2008, some of the same personnel from TMR, as well as a new project manager from Advanced Communica- tions, went back to the project.

By March 2009, the project had already cost $150,000 and only 8 of the locations had imple- mented VoIP. Advanced Communications insisted that the local area networks were obsolete and were unable to carry the expanded load without major upgrades to the bandwidth, the routers, and other telecommunica- tions equipment.

QUESTIONS: 1. Is it time to end this project? Why or why not? 2. What negotiations should have occured between TMR

and Valley Enterprises prior to December 2008? 3. What should a project manager/project coordinator from

Valley Enterprises have done when the project first started to slip?

2-H MANAGING A LATE PROJECT: WHEN TO SAY “WHEN”? IN ACTION

CONCEPTS

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

Most project managers keep abreast of potential risks, even prioritizing them according to their magnitude and importance. Over time, the list of risks will change as some items are removed and others surface. The best project managers, however, work hard to keep risks from having an impact on the schedule and costs associated with the project.

Managing and Controlling the Project 79

I once started on a small project (four people) in which the original members of the project team had not set up any standards for naming electronic files. Two weeks into the project, I was asked to write a piece of code that would be referenced by other files that had already been written. When I finished my piece, I had to go back to the other files and make changes to reflect my new work. The only problem was that the lead programmer decided to name the files using his initials (e.g., GG1.prg, GG2.prg, GG3.prg)—and there were over 200 files! I spent two days opening every one of those files because there was no way to tell what their contents were.

Needless to say, from then on, the team created a code for file names that provided basic information regarding the file’s contents and they kept a log that recorded the file name, its purpose, the date of last update, and programmer for every file on the project.

Barbara Wixom QUESTION: Think about a program that you have written in the past.

Would another programmer be able to make changes to it easily? Why or why not?

2-I POOR NAMING STANDARDS IN ACTION

CONCEPTS

RISK ASSESSMENT

RISK #1: The development of this system likely will be slowed considerably because project team members have not programmed in Java prior to this project.

Likelihood of risk: High probability of risk

Potential impact on the project: This risk likely will increase the time to complete programming tasks by 50%.

Ways to address this risk: It is very important that time and resources are allocated to up-front training in Java for the programmers who are used for this project. Adequate training will reduce the initial learning curve for Java when programming begins. Additionally, outside Java expertise should be brought in for at least some part of the early programming tasks. This person should be used to provide experiential knowledge to the project team so that Java-related issues (of which novice Java programmers would be unaware) are overcome. RISK #2: etc.…FIGURE 2-22

Sample Risk Assessment

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

APPLYING THE CONCEPTS AT TUNE SOURCE

Jason Wells was very excited about managing the Digital Music Download project at Tune Source, but he realized that his project team should move rapidly to deliver at least some parts of the system because of the company’s desire to bring the appli- cation to market as quickly as possible. Therefore, he decided that the project should follow a RAD iterative development methodology, combined with the time- boxing technique. In this way, he could be sure that some version of the system would be operational within several months, even if the final system was delivered at a later date.

Jason knew that Carly Edwards and Tune Source’s top managers wanted at least general ranges for a product delivery date. He expected to spend three weeks planning the project. Therefore, using industry standard percentages, he estimated that the entire project should be complete in 20 weeks (3 weeks/15%). Recall from Figure 2-10 that the planning phase typically takes 15% of the entire project. Jason’s initial plan was to develop the basic music download purchase capability in the first version of the system. The second version will add the subscription purchase capa- bility, and the third version will add the gift card purchase capability.

80 Chapter 2 Project Selection and Management

As Seattle University’s David Umphress has pointed out, watching most organizations develop systems is like watching reruns of Gilligan’s Island. At the beginning of each episode, someone comes up with a cockamamie scheme to get off the island that seems to work for a while, but something goes wrong and the castaways find themselves right back where they started—stuck on the island. Similarly, most companies start new projects with grand ideas that seem to work, only to make a classic mistake and deliver the project behind schedule, over budget, or both. Here we summarize four classic mistakes in the planning and project management aspects of the project and discuss how to avoid them: 1. Overly optimistic schedule: Wishful thinking can lead to an

overly optimistic schedule that causes analysis and design to be cut short (missing key requirements) and puts intense pressure on the programmers, who pro- duce poor code (full of bugs). Solution: Don’t inflate time estimates; instead, explicitly schedule slack time at the end of each phase to account for the variability in estimates, using the mar- gins of error from Figure 2-19.

2. Failing to monitor the schedule: If the team does not regu- larly report progress, no one knows if the project is on schedule.

Solution: Require team members to honestly report progress (or the lack of progress) every week. There is no penalty for reporting a lack of progress, but there are immediate sanctions for a misleading report.

3. Failing to update the schedule: When a part of the sched- ule falls behind (e.g., information gathering uses all of the slack in item 1 above plus 2 weeks), a project team often thinks it can make up the time later by working faster. It can’t. This is an early warning that the entire schedule is too optimistic. Solution: Immediately revise the schedule and inform the project sponsor of the new end date or use timeboxing to reduce functionality or to move it into future versions.

4. Adding people to a late project: When a project misses a schedule, the temptation is to add more people to speed it up. This makes the project take longer because it increases coordination problems and requires staff to take time to explain what has already been done. Solution: Revise the schedule, use timeboxing, throw away bug-filled code, and add people only to work on an isolated part of the project.

Source: Adapted from Rapid Development, Redmond, WA: Microsoft Press, 1996, pp. 29–50, by Steve McConnell.

2-1 AVOIDING CLASSIC PLANNING MISTAKES T I P

PRACTICAL

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

With a general time frame determined, Jason began to identify the tasks that would be needed to complete the system. He used a RAD methodology that Tune Source had in-house, and he borrowed its high-level phases (e.g., analysis) and the major tasks associated with them (e.g., create requirements definition, gather requirements, analyze current system). These were recorded in a work plan created in Microsoft Project. Jason expected to define the steps in much more detail at the beginning of each phase (Figure 2-23).

Staffing the Project

Jason next turned to the task of how to staff his project. According to his earlier esti- mates, it appeared that about three people would be needed to deliver the system.

First, he created a list of the various roles that he needed to fill. He thought he would need several analysts to work with the analysis and design of the Digital Music Download system, as well as an infrastructure analyst to manage the integra- tion of the system with Tune Source’s existing technical environment. Jason also needed people who had good programming skills and who could be responsible for ultimately implementing the system. Kenji, Ming, and Maria are three analysts with strong technical and interpersonal skills (although Kenji is less balanced, having greater technical than interpersonal abilities), and Jason believed that they were available to bring onto this project. He wasn’t certain whether they had experience with the actual Web technology that would be used on the project, but he decided to rely on vendor training or an external consultant to build those skills later when they were needed. Because the project was so small, Jason envisioned all of the team members reporting to him because he would be serving as the project’s manager.

Jason created a staffing plan that captured this information, and he included a special incentive structure in the plan (Figure 2-24). Rapid implementation was very important to the project’s success, so he decided to offer a day off to the team members who contributed to meeting that date. He hoped that this incentive would motivate the team to work very hard. Jason also planned to budget money for pizza and sodas for times when the team worked long hours.

Before he left for the day, Jason drafted a project charter, to be fine-tuned after the team got together for its kick-off meeting (i.e., the first time the project team gets together). The charter listed several norms that Jason wanted to put in place from the start to eliminate any misunderstanding or problems that could come up other- wise (Figure 2-25).

Coordinating Project Activities

Jason wanted the Digital Music Download project to be well coordinated, so he immediately put several practices in place to support his responsibilities. First, he acquired the CASE tool used at Tune Source and set up the product so that it could be used for the analysis-phase tasks (e.g., drawing the data flow diagrams). The team members would likely start creating diagrams and defining components of the system fairly early on. He pulled out some standards that he uses on all develop- ment projects and made a note to review them with his project team at the kick-off meeting for the system. He also had his assistant set up binders for the project deliv- erables that would start rolling in. Already, he was able to include the system request, feasibility analysis, initial work plan, staffing plan, project charter, stan- dards list, and risk assessment.

Applying the Concepts at Tune Source 81

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

82 Chapter 2 Project Selection and Management

FIGURE 2-23 Gantt Chart

Overall analysis

Task NameID

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

Jason, Carly, Ming

Jason, Carly

Ming

Ming

Maria

Maria

Maria

Maria

Ming, Kenji

Maria, Kenji, Ming Maria, Kenji, Ming Jason, Maria, Kenji, Ming Jason, Ming, Kenji, Maria

Kenji

Kenji

Kenji

Ming

Maria, Kenji

Jason

Define Version 1 scope

JAD session

Informal benchmarking Prioritize requirements

Version 1

Version 2

Version 3

Develop use cases Develop process models Develop data models

System architecture

User interface

Database

Write programs

Identify High-Level Requirements

Detailed Requirements

Preliminary Design

Implementation

Acquire HW & SW Construct database

Convert data

Testing

Installation

Programs

10 days

6 days

2 days

4 days

2 days

2 days

61 days

17 days

5 days

12 days

3 days

27 days

5 days

7 days

10 days

5 days

20 days

10 days

4 days

42 days

28 days

10 days

56 days

10 days

7 days

Mon 2/4/13

Fri 2/8/13

Tue 2/12/13

Thu 2/14/13

Mon 2/18/13

Mon 2/18/13

Mon 2/25/13

Mon 2/18/13

Wed 4/24/13

Wed 5/8/13

Tue 5/14/13

Thu 7/11/13

Thu 2/28/13

Wed 3/13/13

Mon 2/25/13

Mon 2/25/13

Thu 3/14/13

Mon 3/25/13

Wed 3/27/13

Mon 2/18/13

Wed 3/17/13

Mon 2/18/13

Mon 2/25/13

Mon 2/4/13 Mon

2/4/13

3

2

5

6

9

9

6

10

11

13,10

13

15

19

22

23

24

16, 10

20, 21

Fri 2/15/13

Mon 2/11/13

Wed 2/13/13

Fri 2/15/13

Mon 5/13/13

Tue 3/12/13

Wed 2/27/13

Tue 3/27/13

Mon 5/13/13

Wed 7/12/13

Mon 8/19/13

Tu e 3/26/13

Mon 5/13/13

Fri 3/8/13

Fri 3/22/13

Fri 3/29/13

Tu e 4/23/13

Tu e 5/7/13

Thu 3/21/13

Fri 2/22/13

Wed 3/13/13

Fri 2/22/13

Tu e 3/12/13

Mon 2/11/13

Thu 2/7/13

StartDuration Finish Predecessors Resource Names

(Continued)

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

Applying the Concepts at Tune Source 83

Jason, Carly, Ming

Maria, Kenji

Jason

Jason, Carly

Ming

Ming

Ming

Maria

Maria

Kenji

Kenji

Kenji

Maria

Maria

Ming, Kenji

Maria, Kenji, Ming

Jason, Maria, Kenji, Ming

Jason, Ming, Kenji, Maria

Maria, Kenji, Ming

February March April May June July August September

2/4 2/11 2/18 2/25 3/4 3/11 3/18 3/25 4/1 4/8 4/15 4/22 4/29 5/6 5/13 5/20 5/27 6/3 6/10 6/17 6/24 7/1 7/8 7/16 7/22 7/29 8/5 8/12 8/19 8/26 9/2 9/9 9/16 9/23

FIGURE 2-23 Gantt Chart

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

84 Chapter 2 Project Selection and Management

Project manager Oversees the project to ensure that it meets its Jason objectives on time and within budget

Infrastructure analyst Ensures that the system conforms to infrastructure Kenji standards at Tune Source; ensures that the Tune Source infrastructure can support the new system

Systems analyst Designs the information system—with a focus Kenji on interfaces with the CD sales system

Systems analyst Designs the information system—with a focus Ming on the process models and interface design

Systems analyst Designs the information system—with a focus Maria on the data models and system performance

Programmer Codes system Ming Programmer Codes system Kenji

Reporting structure: All project team members will report to Jason.

Special incentives: If the deadline for the project is met, all team members who contributed to this goal will receive a free day off, to be taken over the holiday season.

Role Description Assigned To

FIGURE 2-24 Staffing Plan for the Digital Music Download System

Project objective: The Digital Music Download project team will create a working Web-based system to provide digital music downloads to Tune Source’s customers as rapidly as possible.

The Digital Music Download team members will

1. Attend a staff meeting each Friday at 2 P.M. to report on the status of assigned tasks. 2. Update the work plan with actual data each Friday by 5 P.M. 3. Discuss all problems with Jason as soon as they are detected. 4. Agree to support each other when help is needed, especially for tasks that could hold

back the progress of the project. 5. Post important changes to the project on the team bulletin board as they are made.

FIGURE 2-25 Project Charter for the Digital Music Download System

SUMMARY

Project Selection Once the feasibility analysis has been completed, it is submitted back to the approval committee along with a revised system request. The committee then decides whether to approve the project, decline the project, or table it until addi- tional information is available. The project selection process takes into account all of the projects in the organization, using portfolio management. The approval committee weighs many factors and makes trade-offs before a project is selected.

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

Creating the Project Plan There are a number of different project methodologies that can be used to structure and guide systems development projects. Several of the key methodologies are waterfall development and its variations: parallel development and the V-model; rapid application development, including iterative development, system prototyp- ing, and throwaway prototyping; and agile development, including extreme pro- gramming, Scrum, and others. The project manager evaluates characteristics of the project, including factors such as clarity of user requirements, familiarity with tech- nology, complexity, reliability, time frame, and schedule visibility, to select the most appropriate methodology to use for the project.

The project manager then estimates the time frame for the project. Past expe- rience, industry standards, and techniques such as function-point analysis, provide help in this task. The project methodology provides lists of tasks and deliverables for projects, which the project manager modifies, depending on the needs of the specific project. To create a work plan, the project manager refines the tasks into a work breakdown structure, and task time estimates and other information are entered into the work plan.

Staffing involves determining how many people should be assigned to the project, assigning project roles to team members, developing a reporting structure for the team, and matching people’s skills with the needs of the project. Staffing also includes motivating the team to meet the project’s objectives and minimizing conflict among team members. Both motivation and cohesiveness have been found to greatly influence performance of team members in project situations. Team members are motivated most by such nonmonetary things as recognition, achieve- ment, and the work itself. Conflict can be minimized by clearly defining the roles on a project and holding team members accountable for their tasks. Some managers create a project charter that lists the project’s norms and ground rules.

Coordinating project activities includes putting efficient development prac- tices in place and mitigating risk, and these activities occur over the course of the entire SDLC. Three techniques are available to help coordinate activities on a proj- ect: computer-aided software engineering (CASE), standards, and documentation. CASE is a category of software that automates all or part of the development process; standards are formal rules or guidelines that project teams must follow during the project; and documentation includes detailed information about the tasks of the SDLC. Often, documentation is stored in project binder(s) that contain all the deliverables and all the internal communication that takes place—the history of the project.

Managing and Controlling the Project As the project progresses, the project manager collects status reports from the team members and updates the work plan. Graphical tools such as Gantt and PERT charts help depict progress on tasks and clarify critical task dependencies. Project managers try to avoid introducing scope creep or feature creep into the schedule. As inevitable project changes arise, however, project managers try to balance the project size (number of features), time frame, and cost. Estimates may have to be revised as more is learned about the system. Timeboxing can be used to deal with shortened time frames. The project manager also keeps a close watch on the pro- ject risk. A risk assessment should be created and updated to evaluate the likeli- hood of various risks and their potential impact on the project.

Summary 85

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

86 Chapter 2 Project Selection and Management

Agile development CASE repository Chief information officer Computer-aided software

engineering (CASE) Design prototype Documentation Estimation Feature creep Functional lead Group cohesiveness Integrated CASE Interpersonal skills Iterative development Lower CASE

Methodology Milestones Motivation Parallel development Project binder Project management Project manager Project portfolio management Rapid application development Reporting structure Risk assessment Risk management Scope creep Staffing plan Standards

System prototyping Task dependencies Technical skills Technical lead Throwaway prototyping Timeboxing Trade-offs Upper CASE V-model Versions Work breakdown structure Work plan Waterfall development

KEY TERMS

1. Describe how projects are selected in organizations. 2. Describe how project portfolio management is used

by IT departments. 3. Describe the major elements and issues with waterfall

development. 4. Describe the major elements and issues with parallel

development. 5. Describe the major elements and issues with the

V-model. 6. Describe the major elements and issues with itera-

tive development. 7. Describe the major elements and issues with system

prototyping. 8. Describe the major elements and issues with throw-

away prototyping. 9. Describe the major elements and issues with agile

development. 10. Compare and contrast structured design method-

ologies in general with rapid application develop- ment (RAD) methodologies in general.

11. Compare and contrast extreme programming and throwaway prototyping.

12. What are the key factors in selecting a methodology? 13. Why do many projects end up having unreasonable

deadlines? How should a project manager react to unreasonable demands?

14. Name two ways to identify the tasks that need to be accomplished over the course of a project.

15. What is the difference between a methodology and a work plan? How are the two terms related?

16. Some companies hire consulting firms to develop the initial project plans and manage the project, but use their own analysts and programmers to develop the system. Why do you think some companies do this?

17. Describe the differences between a technical lead and a functional lead. How are they similar?

18. Describe three technical skills and three interper- sonal skills that would be very important to have on any project.

19. What are the best ways to motivate a team? What are the worst ways?

20. List three techniques to reduce conflict. 21. What is the difference between upper CASE (com-

puter-aided software engineering) and lower CASE? 22. Describe three types of standards, and provide

examples of each. 23. What belongs in the project binder? How is the

project binder organized? 24. What are the trade-offs that project managers must

manage? 25. What is scope creep, and how can it be managed? 26. What is timeboxing, and why is it used? 27. Create a list of potential risks that could affect the

outcome of a project. 28. Describe the factors that the project manager must

evaluate when a project falls behind schedule.

QUESTIONS

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

Exercises 87

1. What is a function point, and how is it used? 2. Describe the three steps of the function point

approach.

3. What is the formula for calculating the effort for a project?

APPENDIX 2A QUESTIONS

A. Suppose that you are a project manager using the waterfall development methodology on a large and complex project. Your manager has just read the lat- est article in Computerworld that advocates replac- ing the waterfall methodology with prototyping and comes to your office requesting you to switch. What do you say?

B. Suppose that you are an analyst developing a new information system to automate the sales transac- tions and manage inventory for each retail store in a large chain. The system would be installed at each store and would exchange data with a mainframe computer at the company’s head office. What methodology would you use? Why?

C. Suppose that you are an analyst developing a new executive information system (EIS) intended to pro- vide key strategic information from existing corpo- rate databases to senior executives to help in their decision making. What methodology would you use? Why?

D. Suppose that you are an analyst working for a small company to develop an accounting system. What methodology would you use? Why?

E. Visit a project management Web site, such as the Project Management Institute (www.pmi.org). Most have links to project management software products, white papers, and research. Examine some of the links for project management to better understand a variety of Internet sites that contain information related to this chapter.

F. Select a specific project management topic like computer-aided software engineering (CASE), proj- ect management software, or timeboxing, and use the Web search for information on that topic. The

URL listed in question E or any search engine (e.g., Yahoo!, Google,) can provide a starting point for your efforts.

G. Pretend that the career services office at your uni- versity wants to develop a system that collects stu- dent résumés and makes them available to students and recruiters over the Web. Students should be able to input their résumé information into a standard résumé template. The information then is presented in a résumé format, and it also is placed in a data- base that can be queried through an online search form. You have been placed in charge of the project. Develop a plan for estimating the project. How long do you think it would take for you and three other students to complete the project? Provide support for the schedule that you propose.

H. Refer to the situation in question G. You have been told that recruiting season begins a month from today and that the new system must be used. How would you approach this situation? Describe what you can do as the project manager to make sure that your team does not burn out from unreasonable deadlines and commitments.

I. Consider the system described in question G. Create a work plan listing the tasks that will need to be completed to meet the project’s objectives. Create a Gantt chart and a PERT chart in a project manage- ment tool (e.g., Microsoft Project), or use a spread- sheet package to graphically show the high-level tasks of the project.

J. Suppose that you are in charge of the project described in question G, and the project will be staffed by members of your class. Do your classmates have all of the right skills to implement such a

EXERCISES

1. Compare and contrast the Gantt chart and the PERT chart.

2. Of what value is the Gantt chart to the project man- ager? The PERT chart?

APPENDIX 2B QUESTIONS

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

88 Chapter 2 Project Selection and Management

1. Emily Pemberton is an IS project manager facing a dif- ficult situation. Emily works for the First Trust Bank, which has recently acquired the City National Bank. Prior to the acquisition, First Trust and City National were bitter rivals, fiercely competing for market share in the region. Following the acrimonious takeover, numer- ous staff were laid off in many banking areas, including IS. Key individuals were retained from both banks’ IS areas, however, and were assigned to a new consolidated IS department. Emily has been made project manager for the first significant IS project since the takeover, and she faces the task of integrating staffers from both banks on her team. The project they are undertaking will be highly visible within the organization, and the time frame for the project is somewhat demanding. Emily believes that the team can meet the project goals suc- cessfully, but success will require that the team become cohesive quickly and that potential conflicts are avoided. What strategies do you suggest that Emily implement in order to help ensure a successfully functioning project team?

2. Marcus Weber, IS project manager at ICAN Mutual Insurance Co., is reviewing the staffing arrangements for his next major project, the development of an expert system-based underwriters assistant. This new system will involve a whole new way for the underwriters to perform their tasks. The underwriters assistant system will function as sort of an underwriting supervisor, reviewing key elements of each application, checking for consistency in the underwriter’s decisions, and ensuring that no critical factors have been overlooked. The goal of the new system is to improve the quality of the underwriters’ decisions and to improve underwriter productivity. It is expected that the new system will substantially change the way the underwriting staff do their jobs.

Marcus is dismayed to learn that due to budget con- straints, he must choose between one of two available staff members. Barry Filmore has had considerable experience and training in individual and organizational behavior. Barry has worked on several other projects in which the end users had to make significant adjustments

MINICASES

project? If not, how will you go about making sure that the proper skills are available to get the job done?

K. Consider the application that is used at your school to register for classes. Complete a function point worksheet to determine the size of such an applica- tion. You will need to make some assumptions about the application’s interfaces and the various factors that affect its complexity.

L. Read “Your Turn 2-5” in Appendix 2A of this chap- ter. Create a risk assessment that lists the potential risks associated with performing the project, along with ways to address the risks.

M. Pretend that your instructor has asked you and two friends to create a Web page to describe the course to potential students and provide current class infor- mation (e.g., syllabus, assignments, readings) to cur- rent students. You have been assigned the role of leader, so you will need to coordinate your activities and those of your classmates until the project is completed. Describe how you would apply the proj- ect management techniques that you have learned in this chapter to this situation. Include descriptions of how you would create a work plan, staff the project, and coordinate all activities—yours and those of your classmates.

N. Select two project management software packages and research them, using the Web or trade maga- zines. Describe the features of the two packages. If you were a project manager, which one would you use to help support your job? Why?

O. Select two estimation software packages and research them, using the Web or trade magazines. Describe the features of the two packages. If you were a project manager, which one would you use to help support your job? Why?

P. In 1997, Oxford Health Plans had a computer prob- lem that caused the company to overestimate rev- enue and underestimate medical costs. Problems were caused by the migration of its claims process- ing system from the Pick operating system to a UNIX-based system that uses Oracle database soft- ware and hardware from Pyramid Technology. As a result, Oxford’s stock price plummeted, and fixing the system became the number-one priority for the company. Pretend that you have been placed in charge of managing the repair of the claims process- ing system. Obviously, the project team will not be in good spirits. How will you motivate team mem- bers to meet the project’s objectives?

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

Appendix 2A—The Function Point Approach 89

The function point approach20 is an estimating tech- nique that can be used to estimate the size of the new system, the effort that will be required to complete the system, and the time the project will require. This approach requires detailed knowledge of system to be developed. When this knowledge is available, the function

point approach produces a much more precise estimate for the project than the industry standard method men- tioned earlier in Chapter 2.

The function point approach uses a three-step process (Figure 2A-1). First, the project manager esti- mates the size of the project in terms of the number of

APPENDIX 2A—THE FUNCTION POINT APPROACH

to the new system, and Barry seems to have a knack for anticipating problems and smoothing the transition to a new work environment. Marcus had hoped to have Barry’s involvement in this project.

Marcus’s other potential staff member is Kim Danville. Prior to joining ICAN Mutual, Kim had con- siderable work experience with the expert system tech- nologies that ICAN has chosen for this expert system project. Marcus was counting on Kim to help integrate the new expert system technology into ICAN’s systems environment, and also to provide on-the-job training and insights to the other developers on this team.

Given that Marcus’s budget will permit him to add only Barry or Kim to this project team, but not both, what choice do you recommend for him? Justify your answer.

3. Tom, Jan, and Julie are IS majors at Great State Univer- sity. These students have been assigned to a class project by one of their professors, requiring them to develop a new Web-based system to collect and update information

on the IS program’s alumni. This system will be used by the IS graduates to enter job and address information as they graduate, and then make changes to that information as they change jobs and/or addresses. Their professor also has a number of queries that she is interested in being able to implement. Based on their preliminary dis- cussions with their professor, the students have devel- oped this list of system elements:

Inputs: 1 low complexity, 2 medium complexity, 1 high complexity

Outputs: 4 medium complexity Queries: 1 low complexity, 4 medium complexity,

2 high complexity Files: 3 medium complexity Program interfaces: 2 medium complexity

Assume that an adjusted project complexity factor of 1.2 is appropriate for this project. Calculate the total adjusted function points for this project.

FIGURE 2A-1 Estimating Project Time, Using the Function Point Approach

(months)

(person-months) Estimate effort required

Estimate time required

(function points and lines of code)

Estimate system size

20 Two good books that focus on function points are J. Brian Dreger, Function Point Analysis, Englewood Cliffs, NJ: Prentice Hall, 1989; and C. R. Symons, Software Sizing and Estimating: MK II FPA, New York:

John Wiley & Sons, 1991. Additional information on function point analysis can be found at www.ifpug.org.

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

90 Chapter 2 Project Selection and Management

lines of code the new system will require. This size estimate is then converted into the amount of effort required to develop the system in terms of the number of person-months. The estimated effort is then con- verted into an estimated schedule time in terms of the number of months from start to finish.

Step 1: Estimate System Size The first step is to estimate the size of a project by using function points, a concept developed in 1979 by Allen Albrecht of IBM. A function point is a measure of program size that is based on the system’s number and complexity of inputs, outputs, queries, files, and program interfaces.

To calculate the function points for a project, com- ponents are listed on a worksheet to represent the major elements of the system. For example, data-entry screens are kinds of inputs, reports are outputs, and database queries are kinds of queries. (See Figure 2A-2.) The project manager records the total number of each com- ponent that the system will include, and then he or she breaks down the number to show the number of compo- nents that have low, medium, and high complexity. In Figure 2A-2, there are 19 outputs that need to be devel- oped for the system, 4 of which have low complexity, 10 that have medium complexity, and 5 that are very com- plex. After each line is filled in, a total number of points are calculated per line by multiplying each number by a

complexity index. The complexity index values are drawn from function point research and tell us, for example, that a low complexity input is “worth” three function points, while a high complexity output is “worth” seven function points. The line totals are added up to determine the total unadjusted function points (TUFP) for the project.

The complexity of the overall system is greater than the sum of its parts. Things like the familiarity of the pro- ject team with the business area and the technology that will be used to implement the project also may influence how complex a project will be. A project that is very com- plex for a team with little experience might have little complexity for a team with lots of experience. To create a more realistic size for the project, a number of additional system factors such as end-user efficiency, reusability, and data communications are assessed in terms of their effect on the project’s complexity. (See Figure 2A-2.) These assessments are totaled and placed into a formula to cal- culate an adjusted project complexity (APC) factor. The APC factor has a baseline value of 0.65, and the total Pro- cessing Complexity (PC) score (converted to hundredths) is added to the baseline amount. The TUFP value is mul- tiplied by the APC factor to determine the ultimate size of the project in terms of total adjusted function points (TAFP). This number should give the project manager a reasonable idea as to how big the project will be.

Nielsen Media used function point analysis (FPA) for an upgrade to the Global Sample Man- agement System (GSMS) for Nielsen Media/NetRatings, which keeps track of the Internet rating sample, a group of 40,000 homes nationwide that volunteer to participate in ongoing ratings.

In late fall of 1998, Nielsen Media did an FP count based on the current GSMS. (FPA is always easier and more accurate when there is an existing system.) Nielsen Media had its counters—three quality assurance staff—do their FPA, and then input their count into Knowledge-Plan, a productivity modeling tool. In early 1999, seven pro- grammers began writing code for the system, which they were expected to complete in 10 months. As November approached, the project was adding staff to try to meet the deadline. When it became evident that the deadline would not be met, a new FP count was conducted. The

GSMS had grown to 900 FPs. Besides the original 500 plus 20%, there were 300 FPs attributable to features and functions that had crept into the project.

How did that happen? The way it always does: The developers and users had added a button here, a new feature there, and soon the project was much larger than it was originally. But Nielsen Media had put a stake in the ground at the beginning from which they could measure growth along the way.

The best practice is to run the FPA and productivity model at the project’s launch and again when there is a full list of functional requirements. Then do another analy- sis anytime there is a major modification in the functional definition of the project.

Source: “Ratings Game,” CIO Magazine, October 2000, by Bill Roberts.

2A-A FUNCTION POINTS AT NIELSEN IN ACTION

CONCEPTS

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

Appendix 2A—The Function Point Approach 91

FIGURE 2A-2 Function Point-Estimation Worksheet

Description

System Components:

Inputs

Outputs

Queries

Files

Program Interfaces

23

101

39

150

25

338

1 × 6

5 × 7

3 × 6

0 × 15

2 × 10

2 × 4

10 × 5

0 × 4

15 × 10

0 × 7

3 × 3

4 × 4

7 × 3

0 × 7

1 × 5

6

19

10

15

3

Total Unadjusted Function Points (TUFP):

Total Number Low

Complexity

Medium High Total

Overall System:

Data communications

Heavy use configuration

Transaction rate

End-user efficiency

Complex processing

Installation ease

Multiple sites

Performance

Distributed functions

Online data entry

Online update

Reusability

Operational ease

Extensibility

(0 = no effect on processing complexity; 3 = great effect on processing complexity)

Total Processing Complexity (PC):

3

0

0

0

0

0

0

0

2

2

0

0

0

0

7

Adjusted Project Complexity (APC):

.65 + (0.01 x 7 ) = .72

Total Adjusted Function Points (TAFP):

.72 (APC) x 338 (TUFP) = 243 (TAFP)

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

92 Chapter 2 Project Selection and Management

Sometimes a shortcut is used to determine the complexity of the project. Instead of calculating the exact APC score for the 14 factors listed in Figure 2A-2, project managers estimate an APC value that ranges from 0.65 for very simple systems to 1.00 for “normal” systems to as much as 1.35 for complex systems. This estimated APC score is then applied to the TUFP to compute the TAFP. For example, a very simple system that has 200 unadjusted function points would have a size of 130 adjusted function points (200 ! .65 " 130). However, if the system with 200 unadjusted function points were very complex, its function point size would be 270 (200 ! 1.35 " 270).

In the planning phase, the exact nature of the sys- tem has not yet been determined, so it is impossible to know exactly how many inputs, outputs, and so forth will be in the system. It is up to the project manager to make an intelligent guess. Some people feel that using function points this early in a project is not practical for this reason. We believe function points can be a useful tool for understanding a project’s size at any point in the SDLC. Later in the project, once more is known about the system, the project manager will revise the esti- mates, using this better knowledge to produce more accurate results.

Once you have estimated the number of function points, you need to convert the number of function points into the lines of code that will be required to build the system. The number of lines of code depends on the programming language you choose to use. Figure 2A-3 presents a very rough conversion guide for some popu- lar languages.

For example, the system in Figure 2A-2 has 243 function points. If you were to develop the system in COBOL, it would typically require approximately 26,730 lines of code to write it. Conversely, if you were to use Visual Basic, it typically would take 7290 lines of code. If you could develop the system by using a pack- age such as Excel or Access, it would take between 2430 and 9720 lines of code. There is a great range for packages, because different packages enable you to do different things and not all systems can be built with certain packages. Sometimes you end up writing lots of extra code to do some simple function because the pack- age does not have the capabilities you need.

There is also a very important message from the data in this figure. Since there is a direct relationship between lines of code and the amount of effort and time required to develop a system, the choice of development language has a significant impact on the time and cost of projects.

Imagine that job hunting has been going so well that you need to develop a system to sup- port your efforts. The system should allow you to input information about the companies with which you inter- view, the interviews and office visits that you have sched- uled, and the offers that you receive. It should be able to produce reports, such as a company contact list, an inter- view schedule, and an office visit schedule, as well as generate thank-you letters to be brought into a word processor to customize. You also need the system to answer queries, such as the number of interviews by city and your average offer amount.

QUESTIONS: 1. Determine the number of inputs, outputs, interfaces,

files, and queries that this system requires. For each element, determine whether the complexity is low,

medium, or high. Record this information on a work- sheet similar to the one in Figure 2A-2.

2. Calculate the total function points for each line on your worksheet by multiplying the number of each ele- ment with the appropriate complexity score.

3. Sum up the total unadjusted function points. 4. Suppose that the system will be built by you using

Visual Basic (VB). Given your VB skills, multiply the TUFP score by the APC score that best estimates how complex the system will be for you to develop (.65 = simple, 1 = average, 1.35 = complex), and calculate a TAFP value.

5. Using the table in Figure 2A-3, determine the number of lines of code that correspond to VB. Multiply this number by the TAFP to find the total lines of code that your system will require.

2A-1 CALCULATE SYSTEM SIZEY O U R T U R N

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

Step 2: Estimate Effort Required Once an understanding is reached about the size of the system, the next step is to estimate the effort that is required to build it. Effort is a function of the system size combined with production rates (how much work someone can complete in a given time). Much research has been done on software pro- duction rates. One of the most popular algorithms, the COCOMO model,21 was designed by Barry W. Boehm to convert a lines-of-code estimate into a person-month estimate. There are different versions of the COCOMO model that vary with the complexity of the software, the size of the system, the experience of the developers, and the type of software that you are developing (e.g., busi- ness application software such as the registration system

at your university; commercial software such as Word; or system software such as Windows). For small to moderate-size business software projects (i.e., 100,000 lines of code and 10 or fewer programmers), the model is quite simple:

effort (in person-months) ! 1.4 " thousands of lines of code

For example, let’s suppose that we were going to develop a business software system requiring 10,000 lines of code. This project would typically take 14 person- months of effort. If the system in Figure 2A-2 were developed in COBOL (which equates to 26,730 lines of code), it would require about 37.42 person-months of effort.

C 130 COBOL 110 Java 55 C++ 50 Turbo Pascal 50 Visual Basic 30 PowerBuilder 15 HTML 15 Packages (e.g., Access, Excel) 10–40

Source: Capers Jones, Software Productivity Research, http://www.spr.com

Approximate Number of Lines Language of Code per Function Point

FIGURE 2A-3 Converting from Function Points to Lines of Code

Appendix 2A—The Function Point Approach 93

Refer to the project size and lines of code that you calculated in “Your Turn 2A-1.”

QUESTIONS: 1. Determine the effort of your project in person-months

of effort by multiplying your lines of code (in thou- sands) by 1.4.

2. Calculate the schedule time in months for your project by using the formula 3.0 " person-months1/3.

3. Based on your numbers, how much time will it take to complete the project if you are the developer?

2A-2 CALCULATE EFFORT AND SCHEDULE TIMEY O U R T U R N

21 The original COCOMO model is presented by Barry W. Boehm in Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981. Since then, much additional research has been done. The latest version of COCOMO, COCOMO II, is described in B. W. Boehm,

C. Abts, A. W. Brown, S. Chulani, B. K. Clark, E. Horowitz, R. Madachy, D. Reifer, and B. Steece, Software Cost Estimation with COCOMO II, Upper Saddle River, NJ: Prentice Hall PTR, 2000. For the latest updates, see http://sunset.use.edu/csse/research/COCOMOII/cocomo_main.html.

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

94 Chapter 2 Project Selection and Management

Step 3: Estimate Time Required Once the effort is under- stood, the optimal schedule for the project can be esti- mated. Historical data or estimation software can be used as aids, or one rule of thumb is to determine sched- ule by the following equation:

schedule time (months) ! 3.0 " person-months1/3

This equation is widely used, although the specific numbers vary (e.g., some estimators may use 3.5 or 2.5

instead of 3.0). The equation suggests that a project that has an effort of 14 person-months should be scheduled to take a little more than 7 months to complete. Contin- uing the Figure 2A-2 example, the 37.42 person-months would require a little over 10 months. It is important to note that this estimate is for the analysis, design, and implementation phases; it does not include the planning phase.

Project managers utilize several tools to help manage projects. The project work plan, discussed previously, is a critical element of managing projects. In addition, two graphical tools are widely used to understand the rela- tionship between project tasks and to monitor progress on the project.

Gantt Chart

A Gantt chart is a horizontal bar chart that shows the same task information as the project work plan, but in a graphical way. Sometimes a picture really is worth a thousand words, and the Gantt chart can communicate the high-level status of a project much faster and easier than the work plan. Creating a Gantt chart is simple and can be done with a spreadsheet package, graphics soft- ware (e.g., Microsoft VISIO), or a project management package.

First, tasks are listed as rows in the chart, and time is listed across the top in increments based on the needs of the projects. (See Figure 2B-1). A short project may be divided into hours or days, whereas a medium-sized project may be represented in weeks or months. Hori- zontal bars are drawn to represent the duration of each task; the bar’s beginning and end mark exactly when the task will begin and end. As people work on tasks, the appropriate bars are filled in proportionately to how much of the task is finished. Too many tasks on a Gantt chart can become confusing, so it’s best to limit the number of tasks to around 20 to 30. If there are more tasks, break them down into subtasks and create Gantt charts for each level of detail.

There are many things a project manager can see by looking quickly at a Gantt chart. In addition to see- ing how long tasks are and how far along they are, the project manager also can tell which tasks are sequential, which tasks occur at the same time, and which tasks

overlap in some way. He or she can get a quick view of tasks that are ahead of schedule and behind schedule by drawing a vertical line on today’s date. If a bar is not filled in and appears to the left of the line, that task is behind schedule.

There are a few special notations that can be placed on a Gantt chart. Project milestones are shown by upside-down triangles or diamonds. Arrows are drawn between the task bars to show task dependencies. Sometimes, the names of people assigned to each task are listed next to the task bars to show what human resources have been allocated to each task.

PERT Chart

A second graphical way to look at the project work plan information is the PERT chart, which displays the proj- ect tasks in a flowchart. (See Figure 2B-2). PERT (Pro- gram Evaluation and Review Technique) is a network analysis technique that can be used when the individual task time estimates are fairly uncertain. Instead of assigning a specific value as the duration estimate, PERT uses three time estimates: optimistic, most likely, and pessimistic. It then combines the three estimates into a single weighted average estimate using the fol- lowing formula:

The PERT chart is drawn graphically with boxes (called nodes) representing each task and lines (called arcs) showing the dependency between tasks. The time estimates are shown in the nodes. Usually, the partially completed tasks are displayed with a diagonal line through the node, and completed tasks contain crossed lines.

APPENDIX 2B-PROJECT MANAGEMENT TOOLS: THE GANTT CHART AND PERT CHART

PERT weighted ! average

optimistic value # (4 * most likely value) # pessimistic value

6

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

Appendix 2B—Project Management Tools: The Gantt Chart and Pert Chart 95

FIGURE 2B-1 Gantt Chart

- Design Phase

Rejects-handling engine design

- Develop database design document

Megan

Megan

Megan

Joachim

Mei-ling

Kevin

Tomas

Kevin

Task Name

31 days

9 days

9 days

Fri 11/15/13

Mon 12/2/13

Fri 12/13/13

Fri 12/13/13

Fri 12/13/13

Fri 12/13/13

Fri 12/13/13

Fri 12/13/13

Fri 12/13/13

Tue 12/18/13

Fri 11/15/13

Fri 11/15/13

Fri 11/29/13

Wed 11/20/13

Mon 12/9/13

Mon 12/9/13

Mon 12/9/13

Thu 12/26/13

Thu 12/26/13

Fri 12/6/13

Fri 12/6/13

Mon 12/2/13

Mon 12/2/13

Fri 12/27/13

Thu 12/12/13

Wed 12/25/13 3,4

3,4

Wed 12/25/13

Wed 12/25/13

Wed 12/25/13

Wed 12/25/13

Wed 12/25/13

Thu 12/19/13

Fri 12/20/13

Fri 11/29/13

Wed 12/4/13

Thu 12/19/13

Thu 12/19/13

Thu 12/12/13

Mon 12/16/13

Fri 12/27/13

Fri 12/27/13

Fri 12/20/13

Tue 12/17/13

Tue 12/17/13

Thu 12/12/13

Thu 12/12/13

Duration Start Finish Prede. 15, '13 22, '13 Nov Dec

6, '13 13, '13 20, '13 27, '13 Jan

3, '1429, '13

Staging database design 9 days

Suspense database design 9 days

9 days

9 days

- Develop rejects-handling design document

- Develop OLAP design document

Universe design 9 days

- Develop OLAP design part 1 8 days

High-priority reports design 8 days

9 days

9 days

2 days

2 days

- Develop application design document

GCCR maintenance application design

- ETL design document

Data export utility design

26 days- Application design document

User authentication

Web entry application UI design sign-off Web entry forms and database model validation

- Functional requirements document

- Application design 9 days

4 days

Call logging 2 days

Search 3 days

Web entry application UI design 26 days

1 day

11 days

9 days

Chantelle

Chantelle

Chantelle

Joachim

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

96 Chapter 2 Project Selection and Management

FIGURE 2B-2 PERT Chart

Develop database design document

Start: 12/2/13 ID: 2 Finish: 12/12/13 Dur: 9 days Comp: 0%

Develop OLAP design part 1 Start: 12/6/13 ID: 9 Finish: 12/0/13 Dur: 8 days Comp: 0%

Develop application design document

Start: 12/13/13 ID: 11 Finish: 12/25/13 Dur: 9 days Comp: 0%

ETL design document Start: 12/26/13 ID: 13 Finish: 12/27/13 Dur: 2 days Comp: 0%

Application design document

Start: 11/15/13 ID: 15 Finish: 12/19/13 Dur: 26 days Comp: 0%

Functional requirements document

Start: 12/9/13 ID: 19 Finish: 12/19/13 Dur: 9 days Comp: 0%

Design phase Start: 11/15/13 ID: 1 Finish: 12/27/13 Dur: 31 days Comp: 0%

Develop rejects-handling design document

Start: 12/18/13 ID: 5 Finish: 12/25/13 Dur: 9 days Comp: 0%

Develop OLAP design document

Start: 12/13/13 ID: 7 Finish: 12/25/13 Dur: 9 days Comp: 0%

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

Appendix 2B—Project Management Tools: The Gantt Chart and Pert Chart 97

PERT charts are the best way to communicate task dependencies because they lay out the tasks in the order in which they need to be completed. The critical path method (CPM) allows the identification of the critical path in the network, the longest path from project incep- tion to completion. The critical path shows all of the tasks that must be completed on schedule for the project as a whole to finish on schedule. If any of the tasks on the critical path (called critical tasks) takes longer than

expected, the entire project will fall behind. CPM can be used with or without PERT.

Project management software packages like Microsoft Project enable the project manager to input the work plan once and then display the information in many different formats. You can toggle between the work plan, a Gantt chart, and a PERT chart, depending on your project management needs.

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

  • Copyright
  • Preface
  • Brief Contents
  • Contents
  • PART ONE: PLANNING PHASE
    • CHAPTER 1: THE SYSTEMS ANALYST AND INFORMATION SYSTEMS DEVELOPMENT
      • Introduction
      • The Systems Analyst
        • Systems Analyst Skills
        • Systems Analyst Roles
      • The Systems Development Life Cycle
        • Planning
        • Analysis
        • Design
        • Implementation
      • Project Identification and Initiation
        • System Request
        • Applying the Concepts at Tune Source
      • Feasibility Analysis
        • Technical Feasibility
        • Economic Feasibility
        • Organizational Feasibility
        • Applying the Concepts at Tune Source
      • Summary
      • Appendix 1A—Detailed Economic Feasibility Analysis for Tune Source
    • CHAPTER 2: PROJECT SELECTION AND MANAGEMENT
      • Introduction
      • Project Selection
        • Applying the Concepts at Tune Source
      • Creating the Project Plan
        • Project Methodology Options
        • CASE Tools
        • Selecting the Appropriate Development Methodology
        • Estimating the Project Time Frame
        • Developing the Work Plan
      • Staffing The Project
        • Staffing Plan
        • Coordinating Project Activities
      • Managing and Controlling The Project
        • Refining Estimates
        • Managing Scope
        • Timeboxing
        • Managing Risk
      • Applying The Concepts At Tune Source
        • Staffing the Project
        • Coordinating Project Activities
      • Summary
      • Question Chapter 02
      • Appendix 2A: The Function Point Approach
      • Appendix 2B: Project Management Tools: The Gantt Chart and PERT Chart
      • Gantt Chart
      • PERT Chart
  • PART TWO: ANALYSIS PHASE
    • CHAPTER 3: REQUIREMENTS DETERMINATION
      • Introduction
      • The Analysis Phase
      • Requirements Determination
        • What Is a Requirement?
        • The Process of Determining Requirements
        • The Requirements Definition Statement
      • Requirements Elicitation Techniques
        • Requirements Elicitation in Practice
        • Interviews
        • Joint Application Development (JAD)
        • Questionnaires
        • Document Analysis
        • Observation
        • Selecting the Appropriate Techniques
      • Requirements Analysis Strategies
        • Problem Analysis
        • Root Cause Analysis
        • Duration Analysis
        • Activity-Based Costing
        • Informal Benchmarking
        • Outcome Analysis
        • Technology Analysis
        • Activity Elimination
        • Comparing Analysis Strategies
      • Applying The Concepts At Tune Source
        • Eliciting and Analyzing Requirements
        • Requirements Definition
        • System Proposal
      • Summary
      • Questions Chapter 03
    • CHAPTER 4: USE CASE ANALYSIS
      • Introduction
      • Use Cases
        • Elements of a Use Case
        • Alternative Use Case Formats
        • Use Cases and the Functional Requirements
        • Use Cases and Testing
        • Building Use Cases
      • Applying The Concepts At Tune Source
        • Identifying the Major Use Cases
        • Elaborating on the Use Cases
      • Summary
    • CHAPTER 5: PROCESS MODELING
      • Introduction
      • Data Flow Diagrams
        • Reading Data Flow Diagrams
        • Elements of Data Flow Diagrams
        • Using Data Flow Diagrams to Define Business Processes
        • Process Descriptions
      • Creating Data Flow Diagrams
        • Creating the Context Diagram
        • Creating Data Flow Diagram Fragments
        • Creating the Level 0 Data Flow Diagram
        • Creating Level 1 Data Flow Diagrams (and Below)
        • Validating the Data Flow Diagrams
      • Applying the Concepts At Tune Source
        • Creating the Context Diagram
        • Creating Data Flow Diagram Fragments
        • Creating the Level 0 Data Flow Diagram
        • Creating Level 1 Data Flow Diagrams (and Below)
        • Validating the Data Flow Diagrams
      • Summary
    • CHAPTER 6: DATA MODELING
      • Introduction
      • The Entity Relationship Diagram
        • Reading an Entity Relationship Diagram
        • Elements of an Entity Relationship Diagram
        • The Data Dictionary and Metadata
      • Creating An Entity Relationship Diagram
        • Building Entity Relationship Diagrams
        • Advanced Syntax
        • Applying the Concepts at Tune Source
      • Validating An Erd
        • Design Guidelines
        • Normalization
        • Balancing Entity Relationship Diagrams with Data Flow Diagrams
      • Summary
      • Appendix 6A: Normalizing the Data Model
  • PART THREE: DESIGN PHASE
    • CHAPTER 7: MOVING INTO DESIGN
      • Introduction
      • Transition from Requirements to Design
      • System Acquisition Strategies
        • Custom Development
        • Packaged Software
        • Outsourcing
      • Influences on the Acquisition Strategy
        • Business Need
        • In-House Experience
        • Project Skills
        • Project Management
        • Time Frame
      • Selecting an Acquisition Strategy
        • Alternative Matrix
        • Applying the Concepts at Tune Source
      • Summary
    • CHAPTER 8: ARCHITECTURE DESIGN
      • Introduction
      • Elements of an Architecture Design
        • Architectural Components
        • Client–Server Architectures
        • Client–Server Tiers
        • Less Common Architectures
        • Advances in Architecture Configurations
        • Comparing Architecture Options
      • Creating An Architecture Design
        • Operational Requirements
        • Performance Requirements
        • Security Requirements
        • Cultural and Political Requirements
        • Designing the Architecture
      • Hardware And Software Specification
      • Applying The Concepts At Tune Source
        • Creating an Architecture Design
        • Hardware and Software Specification
      • Summary
    • CHAPTER 9: USER INTERFACE DESIGN
      • Introduction
      • Principles for User Interface Design
        • Layout
        • Content Awareness
        • Aesthetics
        • User Experience
        • Consistency
        • Minimize User Effort
      • User Interface Design Process
        • Use Scenario Development
        • Interface Structure Design
        • Interface Standards Design
        • Interface Design Prototyping
        • Interface Evaluation
      • Navigation Design
        • Basic Principles
        • Types of Navigation Controls
        • Messages
      • Input Design
        • Basic Principles
        • Types of Inputs
        • Input Validation
      • Output Design
        • Basic Principles
        • Types of Outputs
        • Media
      • Applying The Concepts At Tune Source
        • Use Scenario Development
        • Interface Structure Design
        • Interface Standards Design
        • Interface Template Design
        • Design Prototyping
        • Interface Evaluation
      • Summary
    • CHAPTER 10: PROGRAM DESIGN
      • Introduction
      • Moving from Logical to Physical Process Models
        • The Physical Data Flow Diagram
        • Applying the Concepts at Tune Source
      • Designing Programs
      • Structure Chart
        • Syntax
        • Building the Structure Chart
        • Applying the Concepts at Tune Source
        • Design Guidelines
      • Program Specification
        • Syntax
        • Applying the Concepts at Tune Source
      • Summary
    • CHAPTER 11: DATA STORAGE DESIGN
      • Introduction
      • Data Storage Formats
        • Files
        • Databases
        • Selecting a Storage Format
        • Applying the Concepts at Tune Source
      • Moving from Logical to Physical Data Models
        • The Physical Entity Relationship Diagram
        • Revisiting the CRUD Matrix
        • Applying the Concepts at Tune Source
      • Optimizing Data Storage
        • Optimizing Storage Efficiency
        • Optimizing Access Speed
        • Estimating Storage Size
        • Applying the Concepts at Tune Source
      • Summary
  • PART FOUR: IMPLEMENTATION PHASE
    • CHAPTER 12: MOVING INTO IMPLEMENTATION
      • Introduction
      • Managing the Programming Process
        • Assigning Programming Tasks
        • Coordinating Activities
        • Managing the Schedule
      • Testing
        • Test Planning
        • Unit Tests
        • Integration Tests
        • System Tests
        • Acceptance Tests
      • Developing Documentation
        • Types of Documentation
        • Designing Documentation Structure
        • Writing Documentation Topics
        • Identifying Navigation Terms
      • Applying the Concepts at Tune Source
        • Managing Programming
        • Testing
        • Developing User Documentation
      • Summary
    • CHAPTER 13: TRANSITION TO THE NEW SYSTEM
      • Introduction
      • Making the Transition to the New System
      • The Migration Plan
        • Selecting the Conversion Strategy
        • Preparing a Business Contingency Plan
        • Preparing the Technology
        • Preparing People for the New System
        • Understanding Resistance to Change
        • Revising Management Policies
        • Assessing Costs and Benefits
        • Motivating Adoption
        • Enabling Adoption: Training
      • Postimplementation Activities
        • System Support
        • System Maintenance
        • Project Assessment
      • Applying the Concepts at Tune Source
        • Implementation Process
        • Preparing the People
        • Postimplementation Activities
      • Summary
    • CHAPTER 14: THE MOVEMENT TO OBJECTS
      • Introduction
      • Basic Characteristics of Object-Oriented Systems
        • Classes and Objects
        • Methods and Messages
        • Encapsulation and Information Hiding
        • Inheritance
        • Polymorphism and Dynamic Binding
      • Object-Oriented Systems Analysis and Design
        • Use Case Driven
        • Architecture Centric
        • Iterative and Incremental
        • Benefits of Object-Oriented Systems Analysis and Design
      • Unified Modeling Language, Version 2.0
        • The Rational Unified Process (RUP)
        • Four Fundamental UML Diagrams
      • Use Case Diagram
        • Elements of a Use Case Diagram
        • Creating a Use Case Diagram
      • Class Diagram
        • Elements of a Class Diagram
        • Simplifying Class Diagrams
        • Creating a Class Diagram
      • Sequence Diagram
        • Creating a Sequence Diagram
      • Behavioral State Machine Diagram
        • Elements of a Behavioral State Machine Diagram
        • Creating a Behavioral State Machine Diagram
      • Summary
    • INDEX