Module 1 Lesson 3 Project Selection and Management.pdf

1 Module 1 | SYSTEM PLANNING 2 Module 1 | SYSTEM PLANNING Lesson 3: Project Selection and Management SPECIFIC LEARNING OUTCOMES In this lesson, you are expected to: 1. explain how projects are selected in some organizations; 2. explicate how to manage r...

1 Module 1 | SYSTEM PLANNING 2 Module 1 | SYSTEM PLANNING Lesson 3: Project Selection and Management SPECIFIC LEARNING OUTCOMES In this lesson, you are expected to: 1. explain how projects are selected in some organizations; 2. explicate how to manage risk on the project; 3. explain the use of Work Breakdown Structure (WBS) in project management; 4. discuss how to select a project methodology based on project characteristics; 5. develop system development stages to model real-life situation; 6. apply various approaches of SDLC that can be used to structure a development project; 7. apply techniques to coordinate and manage the project; 8. create a project work plan and Gantt Chart; 9. practice ethical reasoning to common workplace situations; 10. value the importance of decision making in selecting projects; PRE-ASSESSMENT Instruction: Read each question carefully, and then encircle the answer that best fits the question. 1. SDLC stands for... a. System development life cycle. b. Software development litigation cycle. c. System development life conditions. d. Software development life cycle. 2. A detailed analysis covers all of these EXCEPT a. The user's needs and requirements b. Acquire hardware and software c. The deficiencies of the old system d. A recommendation of a solution 3. A JAD session is useful for: a. Allowing users to research a preferred solution b. Drawing up a detailed analysis of the old system c. Working with the user to gain data and information about the system d. Allowing the designer of the new system to review documentation 4. The iterative model of system development is also called: a. JAD model b. RAD model 3 Module 1 | SYSTEM PLANNING c. Quick model d. Circular Model 5. Using the waterfall model, a prototype can be developed a. During the Analysis phase b. During the Implementation phase c. During the Development phase d. During the Evaluation phase 6. When should users be trained on a new system? a. During the Analysis phase b. During the Implementation phase c. During the Development phase d. During the Evaluation phase 7. The waterfall model is no longer used for system development as it is outdated. a. True b. False 8. The iterative model allowed developers to move smoothly in between design, development and implementation - and back again. a. True b. False 9. For a small business adding a section to their website, generally the best-suited SDM would be: a. True b. False 10. For a large, multi-user system dealing with sensitive data, generally the best SDM will be. a. True b. False LESSON MAP Project Selection Project Selection and Management Managing Creating and Project Plan Controlling Projects The map presents the process in selecting and managing system projects. 4 Module 1 | SYSTEM PLANNING CORE CONTENTS ENGAGE: INSTRUCTIONS: Answer the question below. Project Selection 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 stakeholders 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 stakeholders 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? 5 Module 1 | SYSTEM PLANNING EXPLORE: Most IT departments face a demand for IT projects that far exceeds the department’s ability to supply them. 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 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. 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. Once selected, a systems development project undergoes a thorough process of project management, the process of planning and controlling the project within a specified time frame, at minimum cost, with the desired outcomes. 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. Although training and software are available to help project managers, unreasonable 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 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: 1. First, the project manager chooses a system development methodology that fits the characteristics of the project. 2. Based on the size of the system, estimates of a time frame are made. 3. Then, a list of tasks to be performed is created that forms the basis of the project work plan. 4. Staffing needs are determined, and the project manager sets in place mechanisms to coordinate the project team throughout the project. 5. Finally, the project manager monitors the project and refines estimates as work proceeds. 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 and new technical infrastructures may be evaluated. Collectively, these endeavors are managed 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 6 Module 1 | SYSTEM PLANNING 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. 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 examine 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. 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 FIGURE 2-1 return for the amount the project costs? Figure 3-1 Ways to Classify Projects (See Figure 3-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 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. 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 7 Module 1 | SYSTEM PLANNING 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; however, 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 underway; or the system does not align well with current or future corporate strategy. Example 1: 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 committee decided to fund the Digital Music Download project. 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. The project management phases consist of: 1. Initiation 2. Planning 3. Execution 4. Control 5. Closure In large organizations or on large projects, the role of project manager is commonly filled 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 of decisions regarding the project, including: determining the best project methodology developing a work plan for the project determining a staffing plan establishing mechanisms to coordinate and control the project Project Methodology Options Systems Development Life Cycle (SDLC) provides the foundation 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 steps and 8 Module 1 | SYSTEM PLANNING 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. Waterfall Model - It describes a development method that is linear and sequential - based on the metaphor that when one phase was finished, the development proceeds to the next phase and there is no going back - does not accept the expected changes and revisions that become necessary with most projects One phase begins when another completes, with little backtracking and looping. Figure 3 -2 Waterfall Model One phase begins when another completes, with little backtracking and looping. Disadvantages 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 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 Different Approaches to System Development Rapid Application Development (RAD) Analogous Situation: When you’re building a skyscraper, you can’t switch up the design halfway through. You need to follow the original path from start to finish. But when you are building software, that isn’t the case. You can change the design, add functionality, and remove things you don’t want, all without harming the end product. That’s a major reason why software needs good development models to be efficient from design to launch. Rapid application development was conceived for this purpose–to develop prototypes rapidly for testing functions and features, without having to worry about how the end product will be affected. Rapid Application Development is a development model prioritizes rapid prototyping and quick feedback over long drawn out development and testing cycles. With rapid application development, developers can make multiple iterations and updates to software rapidly without needing to start a development schedule from scratch each time. 9 Module 1 | SYSTEM PLANNING RAD is a development model that came into existence once developers realized the traditional waterfall model of development was not very effective. Figure 3-3 Rapid Application Development Model The key benefit of a RAD approach is fast project turnaround, making it an attractive choice for developers working in a fast-paced environment like software development. This rapid pace is made possible by RAD’s focus on minimizing the planning stage and maximizing prototype development. By reducing planning time and emphasizing prototype iterations, RAD allows project managers and stakeholders to accurately measure progress and communicate in real time on evolving issues or changes. This results in greater efficiency, faster development, and effective communication. You can break down the process in a few ways, but in general, RAD follows four main phases. Phase 1: Requirements planning This phase is equivalent to a project scoping meeting. Although the planning phase is condensed compared to other project management methodologies, this is a critical step for the ultimate success of the project. During this stage, developers, clients (software users), and team members communicate to determine the goals and expectations for the project as well as current and potential issues that would need to be addressed during the build. A basic breakdown of this stage involves: Researching the current problem Defining the requirements for the project Finalizing the requirements with each stakeholder’s approval It is important that everyone has the opportunity to evaluate the goals and expectations for the project and weigh in. By getting approval from each key stakeholder and developer, teams can avoid miscommunications and costly change orders down the road. Phase 2: User design Once the project is scoped out, it’s time to jump right into development, building out the user design through various prototype iterations. This is the meat and potatoes of the RAD methodology and what sets it apart from other project management methodologies. During this phase: Clients work hand in hand with developers to ensure their needs are being met at every step in the design process. It’s almost like customizable software development where the users can test each prototype of the product, at each stage, to ensure it meets their expectations. All the bugs and kinks are worked out in an iterative process. 10 Module 1 | SYSTEM PLANNING The developer designs a prototype, the client (user) tests it, and then they come together to communicate on what worked and what did not. This method gives developers the opportunity to tweak the model as they go until they reach a satisfactory design. Both the software developers and the clients learn from the experience to make sure there is no potential for something to slip through the cracks. Phase 3: Rapid construction Phase 3 takes the prototypes and beta systems from the design phase and converts them into the working model. Because the majority of the problems and changes were addressed during the thorough iterative design phase, developers can construct the final working model more quickly than they could by following a traditional project management approach. The phase breaks down into several smaller steps: Preparation for rapid construction Program and application development Coding Unit, integration, and system testing The software development team of programmers, coders, testers, and developers work together during this stage to make sure everything is working smoothly and that the end result satisfies the client’s expectations and objectives. This third phase is important because the client still gets to give input throughout the process. They can suggest alterations, changes, or even new ideas that can solve problems as they arise. Phase 4: Cutover This is the implementation phase where the finished product goes to launch. It includes data conversion, testing, and changeover to the new system, as well as user training. All final changes are made while the coders and clients continue to look for bugs in the system. Benefits of RAD methodology RAD is one of the most successful software development programs available today, with numerous benefits for both software development teams as well as their clients. Here are just a few advantages: RAD lets you break the project down into smaller, more manageable tasks. The task-oriented structure allows project managers to optimize their team’s efficiency by assigning tasks according to members’ specialties and experience. Clients get a working product delivered in a shorter time frame. Regular communication and constant feedback between team members and stakeholders increases the efficiency of the design and build process. With a shorter planning phase and a focus on highly iterative design and construction, RAD teams are able to accomplish more in less time without sacrificing client satisfaction. RAD may be conducted in a variety of ways. Iterative development It breaks the overall project into a series of versions that are developed sequentially. The most important and fundamental requirements are bundled into the first version of the system. This version is developed quickly by a mini- 11 Module 1 | SYSTEM PLANNING waterfall process, and once implemented; the users can provide valuable feedback to be incorporated into the next version of the system. 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 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. Figure 3-4 Iterative Development System prototyping It performs the analysis, design, and implementation phases concurrently in order to quickly develop a simplified version of the proposed system and give it to the users for evaluation and feedback. 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 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 evaluate 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. 12 Module 1 | SYSTEM PLANNING Figure 3-5 Iterative Development Throwaway prototyping It 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). 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 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 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 several 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 prototypes 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 system prototyping (because the prototypes do not become the final system), but the approach usually produces more stable and reliable systems. 13 Module 1 | SYSTEM PLANNING Figure 3-6 Iterative Development Agile Development Agile methodology breaks the development process into iterative steps and encourages flexibility, testing and change throughout the life cycle of a project. Agile 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. Cycles are kept short, and the development team focuses on adapting to the current business environment. There are several popular approaches to agile development, including: extreme programming (XP) Scrum dynamic systems development method (DSDM) How does Agile work? 1. Listen for user stories from the customer. 2. Draw a logical workflow model to gain an appreciation for the business decisions represented in the user story. 3. Create new user stories based on the logical model. 4. Develop some display prototypes. In doing so, show the customer what sort of interface they will have. 5. Using feedback from the prototypes and the logical workflow diagrams, develop the system until you create a physical data model Agile Core practices: Iterative and Incremental Modeling Teamwork Simplicity Validation 14 Module 1 | SYSTEM PLANNING Extreme Programming It was in this environment that Kent Beck created extreme programming (XP), an agile project management methodology that supports frequent releases in short development cycles to improve software quality and allow developers to respond to changing customer requirements. Figure 3-7 Extreme Programming (XP) Methodology Values of extreme programming methodology Simplicity: Teams accomplish what has been asked for and nothing more. XP breaks down each step of a major process into smaller, achievable goals for team members to accomplish. Streamlined communication: Teams work together on every part of the project, from gathering requirements to implementing code, and participate in daily stand-up meetings to keep all team members updated. Any concerns or problems are addressed immediately. Consistent, constructive feedback: In XP, teams adapt their process to the project and customer needs, not the other way around. The team should demonstrate their software early and often so they can gather feedback from the customer and make the necessary changes. Respect: Extreme programming encourages an “all for one and one for all” mentality. Each person on the team, regardless of hierarchy, is respected for their contributions. The team respects the opinions of the customers and vice versa. Courage: Team members adapt to changes as they arise and take responsibility for their work. They tell the truth about their progress—there are no “white lies” or excuses for failure to make people feel better. There’s no reason to fear because no one ever works alone. When to use extreme programming? Extreme programming can work well for teams that: Expect their system’s functionality to change every few months. Experience constantly changing requirements or work with customers who aren’t sure what they want the system to do. Want to mitigate project risk, especially around tight deadlines. Include a small number of programmers (between 2 and 12 is preferable). Are able to work closely with customers. 15 Module 1 | SYSTEM PLANNING Are able to create automated unit and functional tests. If collaboration and continuous development are priorities for your team, extreme programming might be worth a try. Because this highly adaptable model requires ongoing feedback from customers, anticipates errors along the way, and requires developers to work together, XP not only ensures a health product release but has also unintentionally improved productivity for development teams everywhere. Rational Unified Process (RUP) Rational Unified Process (RUP) is an object-oriented system development methodology offered by Rational Software which is based on an iterative, incremental approach to systems development. RUP has four phases: 1. Inception 2. Elaboration 3. Construction 4. Transition Figure 3-8 Rational Unified Process Methodology 1. Inception phase - Analysts define the scope - determine the feasibility of the project - understand user requirements - Prepare a software development plan. 2. Elaboration phase - Analysts detail user requirements and develop a baseline architecture - Analysis and design activities constitute the bulk of the elaboration phase 3. Construction phase - The software is actually coded, tested, and documented 4. Transition phase - The system is deployed, and the users are trained and supported. 16 Module 1 | SYSTEM PLANNING In Figure 3-8, the construction phase is generally the longest and the most resource intensive. The elaboration phase is also long, but less resource intensive. The transition phase is resource intensive but short. The inception phase is short and the least resource intensive. The areas of the rectangles in Figure 3-8 provide an estimate of the overall resources allocated to each phase. Each phase can be further divided into iterations. The software is developed incrementally as a series of iterations. Joint Application Development Joint Application Development (JAD) is a software development approach which engages the client and/or the end users for designing and developing the system. This model was designed and put forward by Dr. Chuck Morris and Dr. Tony Crawford of IBM, who propose this model in the late 1970s. As compared to other primitive SDLC model, Joint Application Development model leads to faster progression of the system development which has better client approval. Define Objectives Session Preparation Session Conduct Documentation Figure 3-9 Phases of JAD Model 1. Define Specific Objectives: The facilitator, in partnership with stakeholders, set all the objectives as well as a list of items which is then distributed to other developers and participants to understand and review. This objective contains elements like the scope of this projected system, its potential outcome, technical specification required, etc. 2. Session Preparation: The facilitator is solely responsible for this preparation where all relevant data is collected and sent to other members before time. For better insight, research carried out to know about the system requirement better and gather all the necessary information for development. 3. Session Conduct: Here the facilitator is accountable to identify those issues which have to be working out for making the system error-free. Here the facilitator will serve as a participant but will not have a say regarding any information. 4. Documentation: After the product is developed, the records and published documents are put forward into the meeting so that the stakeholders and consumers can approve it through the meeting. 17 Module 1 | SYSTEM PLANNING Benefits of JAD Model Improved Delivery Time Cost Reduction Better Understanding Improved Quality 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. Selecting the Appropriate Development Methodology 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 having one “approved” methodology to having several methodology options to having no formal policies at all. Many of the development methodologies require the use of new tools and techniques that have a significant 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 significantly 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 technology 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 appropriate if on-site user input is available. 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 project with Ruby), 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 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 18 Module 1 | SYSTEM PLANNING 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 development 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 reliability 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 different 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 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 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. Estimating the Project Time 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. Estimation is the process of assigning projected values for time and effort. Estimation can be performed manually or with the help of an estimation software package like Construx Estimate,TM Costar,TM or KnowledgePLAN®—there are over 50 available on the market. The estimates developed at 19 Module 1 | SYSTEM PLANNING the start of a project 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 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 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 project; they have estimates and methodologies that have been developed and honed over time and applied to hundreds of projects. 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 3-10 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 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 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. Task Information Example Name of the task Perform economic feasibility Start date August 05, 2021 Completion date August 19, 2021 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 Figure 3-10 Task Information 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 20 Module 1 | SYSTEM PLANNING 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 defined first 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 backbone of the project workplan. Figure 3-11 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: 1. by SDLC phase or 2. by product 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 products 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. Figure 3-11 Work Breakdown Structure 21 Module 1 | SYSTEM PLANNING 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 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 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 3-12). 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. Example: Figure 3-12 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. Figure 3-12 Project Workplan 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 project, 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 22 Module 1 | SYSTEM PLANNING 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, and 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 translate 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 communication lines to six, and greater increases lead to more dramatic gains in communication complexity. 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. The rule of thumb is to keep team sizes under 8 to 10 people; therefore, if more people are needed, create subteams. In this way, the project manager can keep the communication 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. 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 3-13 illustrates one possible 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 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. Figure 3-13 Possible Reporting Structure 23 Module 1 | SYSTEM PLANNING 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 are 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 organization’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 motivate the people to make the project a success. Motivation has been found to be the number-one influence on people’s performance, 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 motivation 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 itself, responsibility, advancement, and the chance to learn new skills. 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 3-14 lists some other motivational don’ts that you should avoid to ensure that motivation on the project is as high as possible. 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 If everyone is given the same reward, then high-quality people will believe raise that mediocrity is rewarded—and they will resent it. Make an important decision Buy-in is very important. If the project manager needs to make a decision without the team’s input that greatly affects the members of her team, she should involve them in the decision-making process. Maintain poor working A project team needs a good working environment, or motivation will go conditions down the tubes. This includes lighting, desk space, technology, privacy from interruptions, and reference resources. Figure 3-14 Motivational Don’ts 24 Module 1 | SYSTEM PLANNING Handling Conflict The third component of staffing is organizing the project to minimize conflict 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. 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. 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. Coordinating Project Activities Like all project management responsibilities, the act of coordinating project activities 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 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. CASE Tools Computer-aided software engineering (CASE) It 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 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 information is illustrated through diagrams, which typically are easier to understand. Potentially, 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. Standards Members of a project team need to work together, and most project management software and CASE tools provide access privileges to everyone working on the system. When people work together, however, things can get pretty confusing. 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. When a team forms standards and then follows them, the project can be completed faster because task coordination 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. 25 Module 1 | SYSTEM PLANNING 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 planning phase is good documentation, which includes detailed information about the tasks of the SDLC. Often, the 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 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 controls 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 deadline 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. 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. 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 estimates 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. 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 common 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 reasons: Users may suddenly understand the potential of the new system and realize new functionality that would be useful; developers may discover interesting capabilities to which they become much attached; a senior manager may decide to let this system support a new strategy that was developed at a recent board meeting. Unfortunately, after the project begins, it becomes increasingly difficult to address changing requirements. The ramifications of change become more extensive, 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. 26 Module 1 | SYSTEM PLANNING 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 prototyping could be used so that users “experience” the requirements and better visualize how the system could support their needs. 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 create 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 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 mailing 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 subset of their capabilities. Ironically, most developers agree that, typically, 75% of a system can be provided relatively quickly, with the remaining 25% of the functionality 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 3-15). 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 timeboxing 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 requirements 27 Module 1 | SYSTEM PLANNING are changed (e.g., don’t reduce the time allocated to testing without reducing 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. 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 3-15 Steps for Timeboxing Managing Risk One final facet of project management is risk management, the process of assessing and addressing the risks that are associated with developing a project. Many things can cause risks: weak personnel, scope creep, poor design, and overly optimistic 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 3-16). 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. 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. 28 Module 1 | SYSTEM PLANNING Figure 3-16 Sample Risk Assessment EXPLAIN: Short-answer Questions Instructions: Answer the following questions below. 1. Describe how projects are selected in organizations. ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 2. What is a system development methodology? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 3. What are the key factors in selecting a methodology? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 4. What is work breakdown structure (WBS), and when should it be used? ___________________________________________________________________________ 29 Module 1 | SYSTEM PLANNING ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 5. What is the importance of risk management? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ TOPIC SUMMARY In this lesson, you have learned that: 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 additional 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. Systems development methodology is a standard process followed in an organization to conduct all the steps necessary to analyze, design, implement, and maintain information systems. Systems development life cycle (SDLC) is the traditional methodology used to develop, maintain, and replace information systems. The systems development life cycle (SDLC), with its five major phases: planning, analysis, design, implementation, and maintenance. Planning is the first phase of the SDLC in which an organization’s total information system needs are identified, analyzed, prioritized, and arranged. The second phase of the SDLC is analysis in which system requirements are studied and structured. Design is the third phase of the SDLC in which the description of the recommended solution is converted into logical and then physical system specifications. Design can be categorized to two (2); logical design and physical design. Implementation is the fourth phase of the SDLC, in which the information system is coded, tested, installed, and supported in the organization. The final phase of the SDLC is maintenance, in which an information system is systematically repaired and improved. 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. These approaches include the Agile Methodologies, the most famous of which is eXtreme Programming, Rapid Application Development including iterative development, system prototyping, and throwaway 30 Module 1 | SYSTEM PLANNING prototyping; Joint Application Development including extreme programming, Scrum, and others; and Rational Unified Process. The project manager evaluates characteristics of the project, including factors such as clarity of user requirements, familiarity with technology, 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 experience, 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, achievement, 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 practices 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 project: 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. As the project progresses, the project manager collect 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 project risk. A risk assessment should be created and updated to evaluate the likelihood of various risks and their potential impact on the project. 31 Module 1 | SYSTEM PLANNING REFERENCES Books: Dennis, A. et.al. (2012, 2009). System Analysis and Design, 5th Edition. John Wiley & Sons, Inc.. United States of America. George, J. et.al. (2012, 2009, 2006, 2004, 2001). Essential of System Analysis and Design, 5th Edition. Pearson Education, Inc.. United States of America. Kendall, K. et.al. (2014, 2011, 2008). System Analysis and Design, 9th Edition. Pearson Education, Inc.. United States of America. Satzinger, J. et.al. (2016, 2012). System Analysis and Design in Changing World, 7 th Edition. Cengage Learning. United States of America. Tilley, S. et.al. (2017). System Analysis and Design, 11th Edition. Cengage Learning. Boston, United States of America. Valacich, J. et.al.(2017, 2014, 2011). Modern of System Analysis and Design, 8th Edition. Pearson Education, Inc.. United States of America.