Project Selection and Management - Chapter 2 PDF

36 C ha pt er 2 Project Selection and Management INTRODUCTION Most IT departments face a demand for IT projects that far exceeds the department’s ability to supply them. In the past 10 years, business application growth has exploded, and chief information oﬃcers (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: ﬁrst-in, ﬁrst-out; political clout; or the squeaky wheel getting the grease. In recent years, IT depart- ments have collected project information and mapped the projects’ contributions to busi- ness goals, using a project portfolio perspective.2 Project portfolio 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 Manage- ment, 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 speciﬁed 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 coordi- nated. Project management has evolved into an actual profession with many training options and professional certiﬁcation (e.g., project management professional [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, unreasonable demands set by project sponsors and business managers can make project management very diﬃcult. 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 realistic 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 manager chooses a system development methodol- ogy that ﬁts 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. Staﬃng needs are determined, and the project manager sets in place mech- anisms to coordinate the project team throughout the project. Finally, the project manager monitors the project and reﬁnes estimates as work proceeds. 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 ﬂight at Sabre,” SearchCIO.com, November 28, 2007. 4A good book on project management is by Robert K. Wysocki, Eﬀective Project Management: Traditional, Adaptive, Extreme, 7th Ed., New York: John Wiley & Sons, 2013. 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. Project Selection 37 CONCEPTS 2-A Project Portfolio Management: An Essential Tool for IT Departments IN ACTION Information systems are at the core of Sabre Holdings underway and those that are awaiting approval. The Corporation. The Sabre reservation system is the book- software helps prioritize projects, allocate employees, ing system of choice for travel agencies worldwide. monitor projects in real time, flag cost and time vari- Sabre is also the parent company of Travelocity.com, ances, measure the ROI, and help the IT department the second largest online travel agency in the United objectively measure the efficiency and efficacy of IT States. investments. Like many companies, Sabre’s IT department strug- Primavera Systems’ PPM software has enabled gles with many more project requests than it has resources Sabre Holdings to update its queue of projects regularly, to accomplish—as many as 1500 proposals for 600 and projects are now prioritized quarterly instead of funded projects annually. Because of the volatile, com- annually. A study of users of Hewlett Packard’s PPM petitive nature of the travel industry, Sabre is especially Center software found that in all cases, the investment challenged to be certain that IT is doing the right projects in the software paid for itself in a year. Other findings under constantly changing conditions. While traditional were an average 30% increase in on-time projects, a project management techniques focus on getting individ- 12% reduction in budget variance, and a 30% reduction ual projects done, Sabre needs to be able to rapidly in the amount of time IT spent on project reporting. change the entire set of projects it is working on as market Sources: Tucci, Linda, “Project portfolio management takes conditions shift. flight at Sabre,” SearchCIO.com, November 28, 2007. Project portfolio management software collects and Tucci, Linda, “PPM strategy a CIO’s must-have in hard times,” manages information about all projects—those that are SearchCIO.com, March 5, 2008. 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 managed as a program by the IT steering commit- tee. 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. Companies prioritize their business strategies and then assemble and assess project portfolios on the basis of how they meet those strategic needs. The focus on a project’s contribution to an entire portfolio of projects reinforces the need for the feasibility study as described in Chapter 1. The approval committee has the responsibil- ity to evaluate not only the project’s costs and expected beneﬁts, 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 examine the business need (found in the system request) and the project risks (described in the feasibility analysis). Portfolio management takes into consideration the diﬀerent kinds of projects that exist in an organization—large and small, high risk and low risk, strategic and tactical. (See Figure 2-1 for diﬀerent ways of classifying projects.) A good project portfolio will have the most appro- priate mix of projects for the organization’s needs. The committee acts as a portfolio manager, with the goal of maximizing beneﬁts versus costs and balancing 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. 38 C ha pt er 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? FIGURE 2-1 Economic Value How much money does the organization expect to receive in return for the Ways to Classify amount the project costs? Projects 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 busi- ness needs for a part of the company; however, it is not selected. This could happen for many reasons—because there is no money in the budget for another system, the organiza- tion is about to go through some kind of change (e.g., a merger, an implementation of a company-wide system such as ERP), projects that meet the same business require- ments already are underway, or the system does not align well with current or future cor- porate 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 the costs, expected benefits, risks, and strategic alignment of all three projects. Currently, 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 com- mittee decided to fund the Digital Music Download project. YO U R 2-1 To Select or Not to Select T UR N It seems hard to believe that an approval committee would of a company that you have worked for or know about. not select a project that meets real business needs, has a high Describe a scenario in which a project may be very attrac- potential ROI, and has a positive feasibility analysis. Think tive at the project level, but not at the organization level. Creating the Project Plan 39 CONCEPTS 2-B Interview with Lyn McDermid, CIO, Dominion Virginia Power IN ACTION A CIO needs to have a global view when identifying and My second role is to push innovation that creates selecting projects for her organization. I would get lost in value for the business. I manage this by looking at our the trees if I were to manage on a project-by-project basis. lines of business and asking which lines of business cre- Given this, I categorize my projects according to my three ate the most value for the company. These are the areas roles as a CIO, and the mix of my project portfolio for which I should be providing the most value. For changes depending on the current business environment. example, if we had a highly innovative marketing strat- My primary role is to keep the business running. egy, I would push for innovation there. If operations were That means every day when each person comes to work, running smoothly, I would push less for innovation in they can perform his or her job efficiently. I measure this that area. using various service levels, cost, and productivity meas- My third role is strategic, to look beyond today and ures. Projects that keep the business running could have find new opportunities for both IT and the business of a high priority if the business were in the middle of a providing energy. This may include investigating process merger, or a low priority if things were running smoothly, systems, such as automated meter reading or looking into and it were “business as usual.” the possibilities of wireless technologies. Lyn McDermid CONCEPTS 2-C Interview with Carl Wilson, CIO, Marriott Corporation IN ACTION At Marriott, we do not have IT projects—we have busi- Therefore, business projects are proposed, and IT is ness initiatives and strategies that are enabled by IT. As one component of them. These projects are then evalu- a result the only time a traditional “IT project” occurs is ated the same as any other business proposal, such as a when we have an infrastructure upgrade that will lower new resort—by examining the return on investment and costs or leverage better functioning technology. In this other financial measures. case, IT has to make a business case for the upgrade and At the organizational level, I think of projects as prove its value to the company. must-do’s, should-do’s, and nice-to-do’s. The “must- The way IT is involved in business projects in the do’s” are required to achieve core business strategy, such organization is twofold. First, senior IT positions are filled as guest preference. The “should-do’s” help grow the by people with good business understanding. Second, business and enhance the functionality of the enterprise. these people are placed on key business committees and These can be somewhat untested, but good drivers of forums where the real business happens, such as finding growth. The “nice-to-do’s” are more experimental and ways to satisfy guests. Because IT has a seat at the table, look further out into the future. we are able to spot opportunities to support business The organization’s project portfolio should have a strategy. We look for ways in which IT can enable or bet- mix of all three kinds of projects, with a much greater ter support business initiatives as they arise. proportion devoted to the “must-do’s.” Carl Wilson 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 management 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 commonly ﬁlled by a professional specialist in project management. In smaller organizations or on smaller projects, the systems analyst may fill this role. The project manager must make a myriad 40 C ha pt er 2 Project Selection and Management of decisions regarding the project, including determining the best project methodology, developing a work plan for the project, determining a staﬃng plan, and establishing mecha- nisms to coordinate and control the project. Project Methodology Options As we discussed in Chapter 1, the systems development life cycle (SDLC) provides the founda- tion for the processes used to develop an information system. A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of tasks, steps, and deliverables). There are many diﬀerent systems development methodologies, and they vary in terms of the progression that is followed through the phases of the SDLC. Many organizations have their own in-house developed methodologies that explain exactly how each phase of the SDLC is to be performed in that company. In other cases, methodologies are obtained from consulting ﬁrms for their clients to follow; provided by the vendor of the software to be installed; or mandated as a part of projects involving government agencies. Before reviewing several of the predominant methodologies that have evolved over time, we provide a list of project characteristics that will aﬀect the methodology selection decision. Clarity of User Requirements How well do the users and analysts understand the functions and capabilities needed from the new system? Familiarity with Technology How much experience does the project team have with the technology that will be used? System Complexity How much complexity is anticipated in the new system? Does the new system include a wide array of features? Will the system have to integrate with many exist- ing systems? Does it span multiple organizational units, or even multiple organizations? System Reliability Will this system need to be highly reliable or is some downtime tolerable? Short Time Schedules Is the project time frame tight? Schedule Visibility Are the project sponsors, users, or organizational managers anxious to see progress? Keep these factors in mind as you study the methodologies described here. Waterfall Development With waterfall development, the project team proceeds sequentially from one phase to the next (Figure 2-2). The key deliverables for each phase are typically Planning Analysis Design Implementation FIGURE 2-2 System Waterfall Development Creating the Project h1 41 LastPlan voluminous (often, hundreds of pages) and are presented to the approval committee and pro- ject 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 diﬃcult. (Imagine yourself as a salmon trying to swim upstream in a waterfall.) Waterfall development methodologies have several advantages: requirements are identiﬁed long before programming begins, and requirement changes are limited as the project progresses. The key disadvantages are that the design must be completely speciﬁed 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 may be treated almost as an afterthought in the implemen- tation phase. In addition, the deliverables are often a poor communication mechanism, so impor- tant 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 conditions during the analysis phase may need considerable rework to match the environment 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. There are several important variants of waterfall development. The parallel development methodologies evolved to address the lengthy time frame of waterfall development. As shown in Figure 2-3, after the analysis phase, a general design for the whole system is created. Then Planning Analysis Design Design Implementation Subproject 1 Design Subproject 2 Implementation Design Implementation Implementation Subproject 3 System FIGURE 2-3 Parallel Development 42 C ha pt er 2 Project Selection and Management 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 ﬁnal integration of the separate pieces, and the system is delivered. Parallel development reduces the time required to deliver a system, so changes in the busi- ness environment are less likely to produce the need for rework. The approach still suﬀers 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 aﬀect another, and at the end of the project, integrating the subprojects may be quite challenging. The V-model is another variation of waterfall development that pays more explicit atten- tion to testing. As shown in Figure 2-4, the development process proceeds down the left-hand slope of the V, deﬁning requirements and designing system 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, ﬁnally, acceptance testing are performed. A key concept of this model is that as requirements are speciﬁed and components designed, testing for those elements is also deﬁned. In this manner, each level of testing is clearly linked to a part of the analysis or design phase, helping to ensure high quality and relevant testing and maximize test eﬀectiveness. The V-model is simple and straightforward and improves the overall quality of systems through its emphasis on early development of test plans. Projects beneﬁt from an earlier focus on testing, plus the quality assurance personnel’s expertise increases the overall quality of the system design. It still suﬀers 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 (RAD) is a collec- tion of methodologies that emerged in response to the weaknesses of waterfall development Acceptance Acceptance Analysis test design testing System System test design testing Integration Integration Design test design testing Unit Unit test design testing Implementation (coding) FIGURE 2-4 V-Model 5 One of the best RAD books is by Steve McConnell, Rapid Development, Redmond, WA: Microsoft Press, 1996. Creating the Project h1 43 LastPlan 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 devel- oped quickly and into the hands of the users for evaluation and feedback. Computer-aided software engineering (CASE) tools, joint application development (JAD) sessions, fourth-generation/visual programming languages (e.g., Visual Basic.NET), and code genera- tors 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 developed 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 important and fun- damental requirements are bundled into the ﬁrst version of the system. This version is devel- oped quickly by a mini-waterfall process, and once implemented, the users can provide valuable feedback to be incorporated into the next version of the system (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 Planning Analysis Design Analysis Implementation Analysis Design System version 1 Implementation Analysis Design System version 2 Implementation FIGURE 2-5 System version 3 Iterative Development 44 C ha pt er 2 Project Selection and Management be identiﬁed and incorporated into subsequent 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 concur- rently in order to quickly develop a simpliﬁed version of the proposed system and give it to the users for evaluation and feedback (Figure 2-6). The system prototype is a “quick and dirty” version of the system and provides minimal features. Following reaction and comments from the users, the developers reanalyze, redesign, and reimplement a second prototype that cor- rects deﬁciencies and adds more features. This cycle continues until the analysts, users, and sponsors 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 evaluate and reassures users that progress is being made. The approach is very useful when users have dif- ﬁculty expressing requirements for the system. A disadvantage, however, is the lack of careful, methodical analysis before making designs 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. 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, design- ing, and building a design prototype. A design prototype is not intended to be a working system. It contains 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 artiﬁcial data to ensure that they could create a full-blown program successfully. A system that is developed by this type of methodology probably requires several design prototypes during the analysis and design phases. Each of the prototypes is used to minimize Planning Analysis System Design prototype Implementation Implementation FIGURE 2-6 System System Prototyping 6 Our description of the throwaway prototyping is a modiﬁed version of the Spiral Development Model developed by Barry Boehm, “A Spiral Model of Software Development and Enhancement,” Computer, May, 1988, 21(5):61–72. Creating the Project h1 45 LastPlan Planning Analysis Design Analysis Design Design prototype Implementation Implementation FIGURE 2-7 System Throwaway Prototyping the risk associated with the system by conﬁrming that important issues are understood before the real system is built. Once the issues are resolved, the project moves into design and imple- mentation. At this point, the design prototypes are thrown away, which is an important diﬀer- ence between this approach and system prototyping, in which the prototypes evolve into the ﬁnal system. Throwaway prototyping balances the beneﬁts of well-thought-out analysis and design phases with the advantages of using prototypes to reﬁne key issues before a system is built. It may take longer to deliver the ﬁnal system compared with system prototyping (because the prototypes do not become the ﬁnal system), but the approach usually produces more stable and reliable systems. Agile Development Agile development7 is a group of programming-centric methodologies that focus on streamlining the SDLC. Much of the modeling and documentation overhead is eliminated; instead, face-to-face communication is preferred. A project emphasizes simple, iterative application development in which every iteration is a complete software project, including planning, requirements analysis, design, coding, testing, and documentation (Figure 2.8). Cycles are kept short (1–4 weeks), and the development team focuses on adapting to the Planning Analysis Design System Implementation FIGURE 2-8 Extreme Programming 7 For more information, see www.AgileAlliance.org. 46 C ha pt er 2 Project Selection and Management 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 brieﬂy describe XP and Scrum. XP11 emphasizes customer satisfaction and teamwork. Communication, simplicity, feed- back, and courage are core values. Developers communicate with customers and fellow pro- grammers. 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. Standards are very important to minimize confusion, so XP teams use a common set of names, descriptions, and coding prac- tices. XP projects deliver results sooner than even the RAD approaches, and they rarely get bogged down in gathering requirements for the system. XP works well in projects with highly motivated, cohesive, stable, and experienced teams. If the project is not small or the teams are not jelled,12 however, then the likelihood of success for the XP project is reduced. XP requires a great deal of discipline to prevent projects from becom- ing unfocused and chaotic. Furthermore, 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, main- tenance 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 infor- mation system development methodology is in doubt. Finally, the methodology requires consid- erable on-site user involvement, something that is frequently diﬃcult to obtain.13 Scrum has some similarities with XP, including small teams, a series of iterations (called sprints), and a focus on building the system one small piece at a time. Scrum teams obtain requirements at the start of a project or a sprint, then self-organize and form backlogs con- taining their planned approach to the project. The scrum master plays an important role in guiding the team’s progress through the backlogs with repeated sprints. The most essential features are built and delivered in the ﬁrst sprint; additional features are included in subse- quent sprints. Agile versus Waterfall-Based Methodologies Agile development approaches have existed for several decades. Agile development practices were created in part because of dissatisfaction with the sequential, inﬂexible structure of waterfall-based approaches. Presently, agile develop- ment has made inroads into software development organizations, and studies show an even split between agile and waterfall users.14 Many organizations are experimenting with agile even while continuing to employ traditional waterfall approaches (see Concepts in Action 2F). In fact, suggesting that an organization must be “all agile” or “all waterfall” is a false choice. Many software developers actively seek to integrate the best elements of both waterfall and 8 For more information, see www.extremeprogramming.org. 9 For more information, see www.scrum.org. 10 For more information, see www.dsdm.com 11 For more information, see A. Lander, Agile Methodologies, New York: John Wiley & Sons, 2014. 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 Many of the observations described here on the utility of XP as a development approach are based on conversations with Brian Henderson-Sellers. 14 Jan Staﬀord, “Agile and waterfall neck and neck as business side fails to engage.” SearchSoftwareQuality.com, March 16, 2009. Creating the Project h1 47 LastPlan CONCEPTS 2-D Agile Development at Travelers IN ACTION Travelers Insurance Company of Hartford, Connecticut interaction is very deep and profound. The resulting soft- has adopted agile development methodologies. The insur- ware product is delivered quickly—and, generally, with ance field can be competitive, and Travelers wanted to all the features and nuances that the users wanted. have the shortest “time to implement” in the field. Trave- lers set up development teams of six people—two sys- Questions tems analysts, two representatives from the user group (such as claim services), a project manager, and a clerical 1. Could this be done differently, such as through support person. In the agile approach, the users are JAD sessions or having the users review the physically assigned to the development team for the pro- program on a weekly basis, rather than taking the ject. While at first it might seem that the users are just users away from their real jobs to work on sitting around drinking coffee and not doing their regular development? jobs, that is not the case. The rapport that is developed 2. What mindset does an analyst need to work on within the team allows for instant communication. The such an approach? agile into their software development practices. Hybrid agile-waterfall approaches are evolv- ing. 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 ﬁrst 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 every- where!) Many organizations have standards and policies to guide the choice of methodology. You will ﬁnd that organizations may have one “approved” methodology, several methodology options, or have no formal policies at all. In the following paragraphs, we describe the various methodologies’ strengths and weaknesses using the project characteristics we introduced earlier. Figure 2-9 provides a concise summary. Usefulness in Developing System Throwaway Agile Systems Waterfall Parallel V-Model Iterative Prototyping Prototyping Development 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 FIGURE 2-9 Criteria for Selecting a Methodology 48 C ha pt er 2 Project Selection and Management Clarity of User Requirements When it is diﬃcult to state the user requirements clearly, users may need to interact with technology to really understand what a new system can do and how to best apply it to their needs. System prototyping and throwaway prototyping are most appro- priate when user requirements are unclear, because they provide prototypes for users to interact with early in the SDLC. Agile development is suitable if on-site user involvement is available. Familiarity with Technology When the system will use new, unfamiliar technology, applying the new technology early in the methodology will improve the chance of success. Without some familiarity with the base technology, design risks increase. Throwaway prototyping is particu- larly appropriate for situations with limited familiarity with technology, because it explicitly encourages the developers to create design prototypes for areas with high uncertainty. Iterative development is good as well, because opportunities are created to investigate the technology 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 prototypes 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 with- out the ability to get the system or prototypes into users’ hands early on, some key issues may be overlooked. Although iterative development methodologies enable users to interact with the system early in the process, we have observed that project teams who follow these meth- odologies 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? 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 reliability is important, due to its emphasis on testing. Throwaway prototyping excels 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 diﬀerent 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. Short Time Schedules Projects that have short time schedules are well suited for RAD meth- odologies because those methodologies are designed to increase the speed of development. YO U R 2-2 Selecting a Methodology TURN Suppose that you are an analyst for the ABC Company, or elsewhere. ABC has an international network, but the a large consulting firm with offices around the world. offices in each country may use somewhat different The company wants to build a new knowledge manage- hardware and software. ABC management wants the ment system that can identify and track the expertise of system up and running within a year. individual consultants anywhere in the world on the basis of their education and the various consulting pro- Question jects on which they have worked. Assume that this is a What methodology would you recommend that ABC new idea that has never before been attempted in ABC Company use? Why? Creating the Project h1 49 LastPlan CONCEPTS 2-E Where Agile Works and Does Not Work IN ACTION British Airways (BA) experienced problems in software following a traditional methodology was completed in development despite a willing and capable develop- 8 weeks. Only about 25% of the organization has changed ment team. Mike Croucher, brought in as chief software to agile, however. BA recognized a continuing role for the engineer, recommended a move to agile development waterfall methodology in certain areas of the organization after studying BA’s development process. The move- and does not intend to force-fit agile everywhere. At BA, ment to agile was carefully conducted, recognizing that agile is used when the user base demands speed, flexibil- agile represents a huge cultural shift for the developers. ity, and customer-oriented design. Agile is ideal when an BA development team members who were amenable to area requiring small functionality can be developed and and suitable for agile methods were trained as agile deployed earlier, according to Croucher. mentors and coaches to help ease the transition. Converting to agile methods enabled BA to substan- Adapted from: Mondelo, Daniel J. “Where agile development tially shorten the time requirements of certain projects. works and where it doesn’t: A user story.” SearchSoftwareQuality. In some cases, a project that might have taken 9 months com. February 24, 2010. Iterative development, system prototyping, and agile methodologies 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 speciﬁc delivery date. If the project schedule starts to slip, it can be read- justed 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 knowing 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. Close user involvement in agile methodologies ensures that progress is well known. One important item not discussed in Figure 2-9 is the development team’s degree of expe- rience. Many of the RAD and agile development methodologies require the use of new tools and techniques that have a signiﬁcant learning curve. Often, these tools and techniques 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 signiﬁcantly decrease the time needed to deliver a ﬁnal system. 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 pro- ducing 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. Estimation15 is the process of assigning projected values for time and eﬀort. 15 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. 50 C ha pt er 2 Project Selection and Management Estimation can be performed manually or with the help of an estimation software pack- age like Construx Estimate,TM Costar,TM or SPR KnowledgePLAN®—there are over 50 avail- able on the market. The estimates developed at the start of a project are usually based on a range of possible values (e.g., the design phase will take 3–4 months) and gradually become more speciﬁc as the project moves forward (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 eﬀort values during the SDLC so that numbers can be reﬁned along the way, and the next project can beneﬁt from real data. One of the greatest strengths of systems consulting ﬁrms is the past experience that they oﬀer to a project; 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 little 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 standards suggest that a “typical” business application system spends 15% of its eﬀort 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 4 months in the planning phase, then the rest of the project likely will take a total of 22.66 person-months (4 4 0.15 5 22.66). The 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 diﬃcult to take into account the speciﬁcs of your individual project, which may be simpler or more diﬃcult than the “typical” project. The estimating software packages mentioned previously are based upon more complex estimating techniques. A simpliﬁed illustration of this more rigorous approach is explained in Appendix 2A. Developing the Work Plan Once a project manager has a general idea of the size and approximate schedule for the pro- ject, 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 ﬁrst 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 Planning Analysis Design Implementation Typical industry standards for 15 20 35 30 business applications (%) Estimates based on actual Actual: Estimated: Estimated: Estimated: FIGURE 2-10 figures for first stage of SDLC 4 5.33 9.33 8 Estimating Project (person-months) Time Using Industry SDLC, systems development life cycle. Standards Creating the Project h1 51 LastPlan Task Information Example Name of the task Perform economic feasibility Start date Jan 5, 2016 Completion date Jan 19, 2016 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 FIGURE 2-11 Actual time 14.5 hours Task Information the amount of information captured by the work plan depend on the needs of the project (and the detail usually increases as the project progresses). Usually, the work plan is the main component of the project management software that we mentioned earlier. To create a work plan, the project manager identiﬁes the tasks that need to be accom- plished 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, but the methodology that was selected by the project manager should be a valuable resource, providing 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 purchased from consultants or vendors, or books like this textbook can serve as guidance. 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 deﬁned ﬁrst and then broken down into subtasks. Each step is then broken down in turn and numbered in a hierarchical fashion. A list of tasks hierarchically numbered in this way is called a work breakdown structure, and it is the back- bone of the project work plan. 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 ﬁrm decided that it needed to develop a web site, the ﬁrm 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 plan- ning would be feasibility analysis. This task would be broken down into the diﬀerent types of feasibility analysis: technical, economic, and organizational. Each of these would be fur- ther broken down into a series of subtasks. Alternatively, the ﬁrm could organize the work plan along the lines of the diﬀerent products to be developed. In the case of a web site, for example, the products could include applets, application servers, database servers, the vari- ous sets of web pages, a site map, and so on. Each of these products could be decomposed into the diﬀerent tasks associated with the phases of the SDLC. With either approach, once 52 C ha pt er 2 Project Selection and Management Task ID Task Name Duration (days) Dependency Status 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.) FIGURE 2-12 Work Breakdown Structure the overall structure is determined, tasks are identiﬁed and included in the work breakdown structure of the work plan. 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 deﬁne 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 primary 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 breakdown struc- ture, 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 (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 exam- ple, Figure 2-13 shows that tasks 1.2 and 1.3 cannot begin until task 1.1 is completed. Key milestones, or important dates, are also identiﬁed on the work plan. Presentations to the Estimated Actual Duration Start Finish Start Finish Duration Task ID Task Name Assigned To (days) Date Date Date Date variance Dependency Status 1 Design Phase 31 Mon Wed Open 11/14/16 12/28/16 1.1 Develop database design Megan 9 Mon Thurs Open document 12/5/16 12/15/16 1.1.1 Staging database design Megan 9 Mon Thurs Open 12/5/16 12/15/16 1.1.2 Suspense database design Megan 9 Mon Thurs Open 12/5/16 12/15/16 1.2 Develop rejects-handling Megan 9 Fri Wed 1.1.1, 1.1.2 Open design document 12/14/16 12/28/16 1.2.1 Rejects-handling engine Megan 9 Fri Wed Open design 12/16/16 12/2/16 1.3 Develop OLAP design Joachim 9 Fri Wed 1.1.1, 1.1.2 Open document 12/16/16 12/28/16 1.3.1 Universe design Joachim 9 Fri Wed Open 12/16/16 12/28/16 1.4 Develop OLAP design Kevin 8 Fri Tues Open part 1 12/9/16 12/20/16 1.4.1 High-priority reports design Kevin 8 Fri Tues Open 12/9/16 12/20/16 1.5 Develop application design Tomas 9 Fri Wed Open document 12/16/16 12/28/16 1.5.1 Group consolidation and Tomas 9 Fri Wed Open corporate reporting (GCCR) 12/16/16 12/28/16 maintenance application design FIGURE 2-13 Project Work Plan (Continued) 53 54 Estimated Actual Duration Start Finish Start Finish Duration Task ID Task Name Assigned To (days) Date Date Date Date variance Dependency Status 1.6 Extract, transform, load Joachim 2 Thu Fri Open (ETL) design document 12/29/16 12/30/16 1.6.1 Data export utility design Joachim 2 Thu Fri Open 12/29/16 12/30/16 1.7 Application design Mei-ling 26 Mon Tue Open document 11/14/16 12/20/16 1.7.1 Web entry application UI Mei-ling 26 Mon Tue Open design 11/14/16 12/20/16 1.7.2 Web entry application UI Mei-ling 1 Wed Wed Open design sign-off 11/30/16 11/30/16 1.7.3 Web entry forms and data- Kevin 11 Wed Thu Open base model validation 11/23/16 12/8/16 1.8 Functional requirements Chantelle 9 Mon Thu Open document 12/10/16 12/22/16 1.8.1 Application design Chantelle 9 Mon Thu Open 12/12/16 12/22/16 1.8.1.1 User authentication Chantelle 4 Mon Thu Open 12/12/16 12/15/16 1.8.1.2 Call logging Chantelle 2 Fri Mon Open 12/16/16 12/19/16 1.8.1.3 Search Chantelle 3 Tue Thu Open 12/20/16 12/22/16 (Thanks to Priya Padmanhabhan for suggesting this example.) FIGURE 2-13 Project Work Plan Staffing the Project 55 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 Staﬃng 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 conﬂict that will occur over time. The deliverable for this part of project management is a staﬃng plan, which describes the number and kinds of people who will work on the project, the overall reporting structure, and the project charter, which describes the project’s objectives and rules. Staﬃng Plan The ﬁrst step to staﬃng is determining the average number of staﬀ needed for the project. To calculate this ﬁgure, divide the total person-months of eﬀort 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 staﬀ members, although this may change over time as diﬀerent specialists join and leave the team (e.g., business analysts, programmers, technical writers). Many times, the temptation is to assign more staﬀ to a project to shorten the project’s length, but this is not a wise move. Adding staﬀ resources does not translate into increased productivity; staﬀ size and productivity share a disproportionate relationship, mainly because a large number of staﬀ members is more diﬃcult to coordinate. The more a team grows, the more diﬃcult 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 communication lines to six, and greater increases lead to more dramatic gains in communication complexity. Figure 2-14 and Your Turn 2-3 illustrate the impact of adding team members to a project team. One way to reduce eﬃciency losses on teams is to understand the complexity that is cre- ated in numbers and to build in a reporting structure that tempers its eﬀects. The rule of thumb is to keep team sizes under 8–10 people; therefore, if more people are needed, create subteams. In this way, the project manager can keep the communication eﬀective 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 staﬃng 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 eﬀort, 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 program- mers and more technical staﬀ members. There are many structures for project teams; Figure 2-15 illustrates one possible conﬁgu- ration of a project team. After the roles are deﬁned and the structure is in place, the project FIGURE 2-14 Increasing Complexity with Larger Teams Two-person team Four-person team 56 C ha pt er 2 Project Selection and Management Project manager Functional Technical lead lead FIGURE 2-15 Possible Reporting Analyst Analyst Analyst Programmer Programmer Structure manager needs to think about which people can ﬁll each role. Often, one person ﬁlls more than one role on a project team. When you make assignments, remember that people have technical skills and interper- sonal 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 conﬁgured on the basis of a projected number of hits from customers). Interpersonal skills, on the other hand, include interpersonal and communication abilities that are used when dealing with business users, senior management executives, and other members of the project team. They are particularly critical for performing the requirements- gathering activities and when addressing organizational feasibility issues. Each project will require unique technical and interpersonal 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 ﬁlled with people who have the right skills for the job; however, the people who ﬁt 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 com- bination of ﬁnding people with the appropriate skill sets and ﬁnding 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 oﬀ other projects, and resources can be shuﬄed around. This is the most disruptive approach from the organization’s perspective. Another approach is to use outside help—such as a consultant or contractor—to train team members and start them oﬀ on the right foot. Training YO U R 2-3 Communication Complexity T UR N Figure 2-14 shows the increasing number of communi- Questions cation channels that exist as a team grows from two members to four members. Using the figure as a guide, 1. How many communication channels are there in draw the number of communication channels that will the six-member team? The eight-member team? be needed in a six-member team. Now, determine the 2. From your results, how effective do you think a number of communication channels that will be needed 12-member team would be? A 16-member team? in an eight-person team. Staffing the Project 57 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 is not enough; project managers need to motivate the people to make the project a success. Motivation has been found to be the number-one inﬂu- ence on people’s performance,16 but determining how to motivate the team can be quite dif- ﬁcult. You may think that good project managers motivate their staﬀ 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 motivation will not work. Assuming that team members are paid a fair salary, technical employees on project teams are much more motivated by recognition, achievement, the work itself, responsibility, advance- ment, and the chance to learn new skills.17 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 eﬀective 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 Conﬂict The third component of staﬃng is organizing the project to minimize conﬂict among group members. Group cohesiveness (the attraction that members feel to the group and to other members) contributes more to productivity than do project members’ individual capabilities or experiences.18 Clearly deﬁning the roles on the project and holding team members accountable for their tasks is a good way to begin mitigating potential conﬂict on a project. Some project managers develop a project charter that lists the project’s norms and Don’ts Reasons 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 a raise If everyone is given the same reward, then high- quality people will believe that mediocrity is rewarded—and they will resent it. Make an important decision without the Buy-in is very important. If the project manager team’s input needs to 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. FIGURE 2-16 Adapted from: Rapid Development, Redmond, WA: Microsoft Press, 1996, by Steve McConnell. Motivational Don’ts 16 Barry W. Boehm, Software Engineering Economics, Englewood Cliﬀs, 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. 17 F. H. Hertzberg, “One More Time: How Do You Motivate Employees?” Harvard Business Review, 1968, January–February. 18 B. Lakhanpal, “Understanding the Factors Inﬂuencing the Performance of Software Development Groups: An Exploratory Group-Level Analysis,” Information and Software Technology, 1993, 35(8):468–473. 58 C ha pt er 2 Project Selection and Management ground rules. For example, the charter may describe when the project team should be at work, when staﬀ 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 conﬂict to a minimum. Coordinating Project Activities Like all project management responsibilities, the act of coordinating project activities contin- ues throughout the entire project until a system is delivered to the project sponsor and end users. This step includes putting eﬃcient development practices in 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 sec- tion will describe each of these activities in more detail. Computer-Aided Software Engineering Tools 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 system and to store information regarding the system components (often called upper CASE), whereas others are design-phase tools that create the diagrams and then generate code for database tables and system functionality (often called

Project Selection and Management - Chapter 2 PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue