MSIT-121B (Elective 2): Software Project Management and Planning

Transcription

1 1

2 MSIT-121B (Elective 2): Software Project Management and Planning 2

3 Course Design and Editorial Committee Prof. M.G.Krishnan Prof. Vikram Raj Urs Vice Chancellor Dean (Academic) & Convener Karnataka State Open University Karnataka State Open University Mukthagangotri, Mysore Mukthagangotri, Mysore Head of the Department and Course Co-Ordinator Rashmi B.S Assistant Professor & Chairperson DoS in Information Technology Karnataka State Open University Mukthagangotri, Mysore Course Editor Ms. Nandini H.M Assistant professor of Information Technology DoS in Information Technology Karnataka State Open University Mukthagangotri, Mysore Course Writers Dr. H S Nagendra Swamy Associte Professor, DoS in Computer Science, Manasagangothri, University of Mysore, Mysore Dr. Manjunath S Assistant Professor, PG Dept. of Computer Science, JSS College of Arts, Commerce & Science, Oooty road, Mysore. Publisher Registrar Karnataka State Open University Mukthagangotri, Mysore Developed by Academic Section, KSOU, Mysore Karnataka State Open University, 2014 All rights reserved. No part of this work may be reproduced in any form, by mimeograph or any other means, without permission in writing from the Karnataka State Open University. Further information on the Karnataka State Open University Programmes may be obtained from the University s Office at Mukthagangotri, Mysore 6. Printed and Published on behalf of Karnataka State Open University, Mysore-6 by the Registrar (Administration) 3

4 Module 1 Karnataka State Open University Muktagangothri, Mysore Master of Science in Information Technology MSIT 121B Software Project Management and Practices Unit-1 Introduction to Project Management Unit-2 Project Planning Unit-3 Project Scope Management Unit-4 Project Scheduling Module 2 Unit-5 Project Cost Estimation Unit-6 Project Cost Estimation Model Unit-7 Project Quality Management Unit-8 Quality Management Tools Module 3 Unit-9 Human Resource Management Unit-10 Case Study and Issues Involved Unit-11 Planning and Reporting Unit-12 Project Communication Module 4 Unit-13 Risk Management and Case Study Unit-14 Procurement Procedures Unit-15 Contract Administration Unit-16 Project Management Process Groups

5 PREFACE Software project management is the art and science of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled. The main objective of this course is to understand the software project management and their applications; also to acquire knowledge on working principles of project related applications. The overall course is divided into four modules and each module consist of four units. Thus there are totally sixteen units. In summary, module 1 gives introduction to the project management, project planning, scope management and project scheduling. Module 2 covers topics such as cost estimation principles and importance, cost estimation models, Quality management characteristics and importance, Quality management tools and case study. Module 3 discusses issues like Human resources management, Case study and issues involved, Planning and reporting. Some live case study descriptions are also included in this module. In final module of this course, we discuss on risk management. A related case study is given for better understanding of the topic. In the later part this module we discuss on procurement procedures, and Planning, execution and closing of the project. A separate unit is dedicated for case study description, which covers issues like source selection, contract administration, and contract close-out related cases. A detailed examples are included and links for the addition resources are given in reference section. Students are advised to go through the each and every unit and simulate the same with some hypothetical project for better understanding of the concepts. Wish you all a happy reading. UNIT 1 5

6 INTRODUCTION TO PROJECT MANAGEMENT STRUCTURE 1.0 Objectives 1.1 Introduction 1.2 Definition of a Project 1.3 Problems with Software Projects 1.4 Project Management 1.5 Project and Product Life Cycle 1.6 Project Management Framework 1.7 Project Management Knowledge Area 1.8 The Role of Project Manager 1.9 Project Management Tools and Techniques 1.10 Summary 1.11 Keywords 1.12 Questions 1.13 Exercise 1.14 Reference 1.0 OBJECTIVES After studying this unit, you will be able to: Explain the growing need for better project management, especially for information technology projects. Explain what a project is, provide examples of information technology projects, list various attributes of projects, and describe the triple constraint of project management. Describe project management and discuss key elements of the project management framework, including project stakeholders, the project management knowledge areas, the role of project manager and tools and techniques for project management. 6

7 1.1 INTRODUCTION Many people and organizations today have a new or renewed interest in project management. Until the 1980s, project management primarily focused on providing schedule and resource data to top management in the military, computer, and construction industries. Today s project management involves much more, and people in every industry and every country manage projects. New technologies have become a significant factor in many businesses. Software project management encompasses the knowledge, techniques, and tools necessary to manage the development of software products. Software project management remains different from project management in other, more established fields for a number of reasons: Software is a brain product only, unconstrained by the laws of physics or by the limits of manufacturing processes. It is difficult to detect and prevent defects in software. Software can be highly complex. Finally, as a discipline, software development is so young that measurable, effective techniques are not yet available, and those that are available are not well-calibrated. Despite these difficulties, there is an increasing body of knowledge about software project management. Many organizations assert that using project management provides advantages, such as: Better control of financial, physical, and human resources Improved customer relations Shorter development times Lower costs and improved productivity Higher quality and increased reliability Higher profit margins Better internal coordination Positive impact on meeting strategic goals Higher worker morale 1.2 DEFINITION OF A PROJECT 7

8 In order to discuss project management, first, we need to understand the concept of a project. A project is a temporary endeavour undertaken to create a unique product, service, or result. Operations, on the other hand, is work done in organizations to sustain the business. Projects are different from operations in that they end when their objectives have been reached or the project has been terminated. Examples of Information Technology Projects Projects can be large or small and involve one person or thousands of people. They can be done in one day or take years to complete. Information technology projects involve using hardware, software, and/or networks to create a product, service, or result. Examples of information technology projects include the following: A small software development team adds a new feature to an internal software application for the finance department. A college campus upgrades its technology infrastructure to provide wireless internet access across the whole campus. A company develops a new system to increase sales force productivity and customer relationship management. A television network implements a system to allow viewers to vote for contestants and provide other feedback on programs. The automobile industry develops a web site to streamline procurement. A government group develops a system to track child immunizations. A large group of volunteers from organizations throughout the world develops standards for environmentally friendly or green IT. The Triple Constraint Every project is constrained in different ways by its scope, time, and cost goals. These limitations are sometimes referred to in project management as the triple constraint. To create a successful project, a project manager must consider scope, time, and cost and balance these three often-competing goals. He or she must consider the following: Scope: What work will be done as part of the project? What unique product, service, or result does the customer or sponsor expect from the project? How will the scope be verified? 8

9 Time: How long should it take to complete the project? What is the project schedule? How will the team track actual schedule performance? Who can approve changes to the schedule? Cost: What should it cost to complete the project? What is the project s budget? How will costs be tracked? Who can authorize changes to the budget? Managing the triple constraint involves making trade-offs between scope, time, and cost goals for a project. For example, you might need to increase the budget for a project to meet scope and time goals. Alternatively, you might have to reduce the scope of a project to meet time and cost goals. Experienced project managers know that you must decide which aspect of the triple constraint is most important. If time is most important, you must often change the initial scope and/or cost goals to meet the schedule. If scope goals are most important, you may need to adjust time and/or cost goals. Although the triple constraint describes how the basic elements of a project scope, time, and cost interrelate, other elements can also play significant roles. Quality is often a key factor in projects, as is customer or sponsor satisfaction. Some people, in fact, refer to the quadruple constraint of project management, which includes quality as well as scope, time, and cost. Others believe that quality considerations, including customer satisfaction, must be inherent in setting the scope, time, and cost goals of a project. A project team may meet scope, time, and cost goals but fail to meet quality standards or satisfy their sponsor, if they have not adequately addressed these concerns. How can you avoid the problems that occur when you meet scope, time, and cost goals, but lose sight of quality or customer satisfaction? The answer is good project management, which includes more than meeting the triple constraint. 1.3 PROBLEMS WITH SOFTWARE PROJECTS Every software project has to face some problems depending on the domain and scope. The scale, complexity, heterogeneity, different stakeholders with different viewpoints, volatile requirements and other business related problems. 1. Vague and ever-changing requirements 9

10 Fickle clients can be a huge hassle. If a client doesn t know what they want until a certain stage is complete, then schedule those decision points into the project as milestones. It is important to have a clear path mapped out from start to finish because it forces the client to be specific with their requirements, as well as keeping the project on track. Be clear at the outset about what your task is going to be on the project and how much leeway is available. If you will need to be compensated for big revisions or changes in direction, then set a clear outline about the number of adjustments you can make before you need to charge more. If you can, quantify these adjustments with a number; it makes it much easier to keep track of things. 2. Client is slow with communication People are busy, but it s tough for you to move forward on a project if you can never get answers from the person you re working with. The good news is that you will drastically increase your response rate if you do a little bit of work ahead of time. Instead of waiting for the back-andforth discourse to finally take place, simply start moving in the direction that you think is best and then seek verification. This strategy makes it easy for your client to quickly say yes (or no). 3. The project does not start on time You know that you need to take on the work when you can get it, but now you are worried that you will not be able to start all of your projects on time as you promised. Or perhaps your client says you are a top priority - but tomorrow a different project becomes more important. If the holdup is on your end, then it is important that you do something to jump-start the project - even if it is in a really small way. Give the client a call to discuss their expectations and set a more realistic timeframe for the first milestone. This could take as little as a few minutes, but it makes the client feel like things have started. However, beware of doing this more than once. That is known as stringing the client along - they do not take that too well, and for good reason. If the holdup is on their end, then you need to communicate very clearly how that alters things moving forward. Be sure to let them know exactly how this change affects the completion dates of future milestones and you should check the revised schedule against other commitments with other projects. 4. You try to manage every project the same way 10

11 There has never been a project that has the same circumstance, requirements, and needs as another project. Situations, people, and goals change over time. Instead of squeezing every project into the same template, spend some time crafting milestones specific to the needs of each project. Every job requires specific milestones that meet the schedules of all parties involved. To put it simply, your schedule changes all the time. That means the way you plan your projects needs to change as well. 5. The client does not like what you created If this happens often, then there is a communication issue that needs to be addressed. Make sure you understand not just the technical requirements of a project, but also the underlying rationale of your clients. Why did they decide to do this in the first place? What are they hoping your work will enable them to do when all is said and done? How do they see your project fitting in with their overall strategic vision? Good project managers create a shared vision between all parties. It is your responsibility to understand the direction of your particular project as well as the overall strategy of your client and then to make sure those two items match up. 6. Your point of contact does not seem to care about your project Working on a project that is not high on a client s priority list can be frustrating. In some cases, the person responsible for communicating with you has little or no interest in your project. The completed product will have no direct effect on their job, they are hard to ask questions to, even harder to get answers from, and they provide minimal guidance. This issue is best solved when choosing a client. So, when screening potential clients, do your best to find out if the contact person has a vested interest in the project. Pay attention to their awareness about potential problems or risks you could run into, their level of urgency when scheduling this project in their calendar, and their desire to communicate with you quickly and consistently from the beginning. If they brush these issues to the side, then it is worth your time to talk with someone else and establish a second point of contact before deciding whether to take on the project or to avoid the project all together. 7. Too much time is spent solving problems after projects are "Live" 11

12 There are bound to be a few bugs here and there, but this is a classic problem caused by focusing too much on production, and not enough on testing. If this continually becomes an issue, then there are two possible solutions. First, schedule in more time to test your projects from the start. Double your typical testing time if needed. Yes, it will stretch your schedule further, but in the long run, it will save you from the countless little problems that prevent your days from being productive. Second, if your ongoing issues are a result of clients constantly wanting you to tweak something here and there, then you need to be clearer about what you do and don t provide with your services. When you set guidelines with a client at the beginning of a project, you need to state very clearly that your work ends after the final product is created and handed off. This can be avoided by outlining boundaries at the beginning of a project that explicitly state that additional service after delivery will cost extra. 1.4 PROJECT MANAGEMENT Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. Project managers must not only strive to meet specific scope, time, cost, and quality goals of projects, they must also facilitate the entire process to meet the needs and expectations of the people involved in or affected by project activities. Stages of Project A software project undergoes a series of identifiable stages during its life time. Following are the various stages of a project: Feasibility Study: The aim of the feasibility study is to determine whether developing the product is financially and technically feasible. The data collected in this phase are analyzed to arrive at the following: An abstract definition of the problem. Formulation of the different solution strategies. 12

13 Examination of alternative solution strategies and their benefits, indicating resources required, development, cost and time in respect of each of the alternative solutions. A cost/benefit analysis is performed to determine which solution is the best. At this stage, it may also be determined whether any of the solutions is not feasible due to high cost, resource constraints, or extraordinary technical reasons. Cost-Benefit Analysis (CBA): It estimates and totals up the equivalent money value of the benefits and costs to the community of projects to establish whether they are worthwhile. These projects may be dams and highways or can be training programs and health care systems. Following are the principles of cost benefit analysis in any project: There must be a common unit of measurement CBA valuations should represent consumers or producers valuations as revealed by their actual behaviour Benefits are usually measured by market choices The analysis of a project should involve a With versus Without comparison Cost benefit analysis involves a particular study area Double counting of benefits or costs must be avoided Project planning: Project planning is a discipline for stating how to complete a project within a certain timeframe, usually with defined stages, and with designated resources. The main purpose of Project Planning is to guide the execution of projects. The key outputs of Project Planning include: Team contract Scope statement Work breakdown structure Project schedule in the form of Gantt chart with all dependencies and resources entered List of prioritized risks Project Execution: The Project execution takes most of the time and resources in Project Management. Project Managers must use their leadership skills to handle the various challenges that occur during project execution. Project Sponsors and customers focus on the deliverables related to providing the products, services or results desired from the project. A milestone report will help the Project Manager to keep the focus on completing major milestones. 13

14 1.5 PROJECT AND PRODUCT LIFE CYCLE A life cycle model prescribes the different activities that need to be carried out to develop a software product and the sequencing of these activities. A software life cycle model is a descriptive and diagrammatic representation of the software life cycle. Following are the various stages of a software project: Requirement Analysis and Specification: The aim of the requirement analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities: Requirement analysis Requirement specification The goal of the requirements analysis is to collect and analyze all related data and information with a view to understanding the customer requirements clearly and weeding out inconsistencies and incompleteness in these requirements. During requirements specification, the user requirements are properly organized and documented in a SRS document. The SRS document addresses the functional requirements, the nonfunctional requirements and the special requirements on the maintenance and development of the software product, if any. Design: The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase the software architecture is derived from the SRS document. Two distinctly different approaches are available: the traditional design approach and the object-oriented design approach. Traditional design approach: Traditional design consists of two different activities; first a structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined. This is followed by a structured design activity. During structured design, the results of structured analysis are transformed into the software design. 14

15 Object-oriented design approach: In this technique, various objects that occur in the problem domain and the solution domain are first identified, and the different relationships that exist among these objects are identified. The object structure is further refined to obtain the detailed design. Coding and Unit Testing: The purpose of this phase (also called the implementation phase) of software development is to translate the software design into source code. The end product of the implementation phase is a set of program modules that have been individually tested. Integration and System Testing: During this phase the different modules are integrated in a planned manner. The different modules making up a system are almost never integrated in a single shot. The goal of system testing is to ensure that the developed system functions according to its requirements as specified in the SRS document. The system testing usually consisting of three different kinds of testing activities: α-testing β-testing, and Acceptance testing Maintenance: Maintenance involves performing any one or more of the following three kinds of activities: 1. Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. 2. Improving the implementation of the system and enhancing the functionalities of the system according to the customer s requirements. This is called perfective maintenance. 3. Porting the software to a new environment, e.g. to a new computer or to a new operating system. This is called adaptive maintenance. 1.6 PROJECT MANAGEMENT FRAMEWORK Figure 1-1 illustrates a framework to help you understand project management. Key elements of this framework include the project stakeholders, project management knowledge areas, project management tools and techniques, and the contribution of successful projects to the enterprise. 15

16 Project Stakeholders: Stakeholders are the people involved in or affected by project activities and include the project sponsor, project team, support staff, customers, users, suppliers, and even opponents of the project. These stakeholders often have very different needs and expectations. For example, building a new house is a well-known example of a project. There are several stakeholders involved in a home construction project. Figure 1-1 Project Management Framework The project sponsors would be the potential new homeowners. They would be the people paying for the house and could be on a very tight budget, so they would expect the contractor to provide accurate estimates of the costs involved in building the house. They would also need a realistic idea of when they could move in and what type of home they could afford given their budget constraints. The new homeowners would have to make important decisions to keep the costs of the house within their budget. Can they afford to finish the basement right away? If they can afford to finish the basement, will it affect the projected move-in date? In this example, the project sponsors are also the customers and users for the product, which is the house. The project manager in this example would normally be the general contractor responsible for building the house. He or she needs to work with all the project stakeholders to meet their needs and expectations. The project team for building the house would include several construction workers, electricians, carpenters, and so on. These stakeholders would need to know exactly what work 16

17 they must do and when they need to do it. They would need to know if the required materials and equipment will be at the construction site or if they are expected to provide the materials and equipment. Their work would need to be coordinated since there are many interrelated factors involved. For example, the carpenter cannot put in kitchen cabinets until the walls are completed. Support staff might include the buyers employers, the general contractor s administrative assistant, and other people who support other stakeholders. The buyers employers might expect their employees to still complete their work but allow some flexibility so they can visit the building site or take phone calls related to building the house. The contractor s administrative assistant would support the project by coordinating meetings between the buyers, the contractor, suppliers, and so on. Building a house requires many suppliers. The suppliers would provide the wood, windows, flooring materials, appliances, and so on. Suppliers would expect exact details on what items they need to provide, where and when to deliver those items, and so on. There may or may not be opponents of a project. In this example, there might be a neighbour who opposes the project because the workers are making so much noise that she cannot concentrate on her work at home, or the noise might wake her sleeping children. She might interrupt the workers to voice her complaints or even file a formal complaint. Or, the neighbourhood might have association rules concerning new home design and construction. If the homeowners did not follow these rules, they might have to halt construction due to legal issues. As you can see from this example, there are many different stakeholders on projects, and they often have different interests. Stakeholders needs and expectations are important in the beginning and throughout the life of a project. Successful project managers develop good relationships with project stakeholders to understand and meet their needs and expectations. 1.7 PROJECT MANAGEMENT KNOWLEDGE AREAS Project management knowledge areas describe the key competencies that project managers must develop. The center of Figure 1-1 shows the nine knowledge areas of project management. The four core knowledge areas of project management include project scope, time, cost, and 17

18 quality management. These are core knowledge areas because they lead to specific project objectives. Project scope management involves defining and managing all the work required to complete the project successfully. Project time management includes estimating how long it will take to complete the work, developing an acceptable project schedule, and ensuring timely completion of the project. Project cost management consists of preparing and managing the budget for the project. Project quality management ensures that the project will satisfy the stated or implied needs for which it was undertaken. The four facilitating knowledge areas of project management are human resource, communications, risk, and procurement management. These are called facilitating knowledge areas because they are the processes through which the project objectives are achieved. Project human resource management is concerned with making effective use of the people involved with the project. Project communications management involves generating, collecting, disseminating, and storing project information. Project risk management includes identifying, analyzing, and responding to risks related to the project. Project procurement management involves acquiring or procuring goods and services for a project from outside the performing organization. Project integration management, the ninth knowledge area, is an overarching function that affects and is affected by all of the other knowledge areas. Project managers must have knowledge and skills in all nine of these areas. This text includes an entire chapter on each of these knowledge areas because all of them are crucial to project success. 1.8 THE ROLE OF PROJECT MANAGER You have already read that project managers must work closely with the other stakeholders on a project, especially the sponsor and project team. They are also more effective if they are familiar with the nine project management knowledge areas and the various tools and techniques related 18

19 to project management. Experienced project managers help projects succeed. But what do project managers do exactly? What skills do they really need to do a good job? The next section provides brief answers to these questions, and the rest of this book gives more insight into the role of the project manager. Even if you never become a project manager, you will probably be part of a project team, and it is important for team members to help their project managers. Project Manager Job Description A project manager can have many different job descriptions, which can vary tremendously based on the organization and the project. For example, Monster.com includes thousands of job listings for project managers. They even have a job category for project/program managers. Here are a few edited postings: Project manager for a consulting firm: Plans, schedules, and controls activities to fulfill identified objectives applying technical, theoretical, and managerial skills to satisfy project requirements. Coordinates and integrates team and individual efforts and builds positive professional relationships with clients and associates. IT project manager for a financial services firm: Manages, prioritizes, develops, and implements information technology solutions to meet business needs. Prepares and executes project plans using project management software following a standard methodology. Establishes cross-functional end-user teams defining and implementing projects on time and within budget. Acts as a liaison between third-party service providers and end-users to develop and implement technology solutions. Participates in vendor contract development and budget management and provides post implementation support. IT project manager for a non-profit consulting firm: Responsibilities include business analysis, requirements gathering, project planning, budget estimating, development, testing, and implementation. Responsible for working with various resource providers to ensure development is completed in a timely, high quality, and cost-effective manner. The job description for a project manager can vary by industry and by organization, but there are similar tasks that most project managers perform regardless of these differences. In fact, project management is a skill needed in every major information technology field, from database administrator to network specialist to technical writer. 19

20 1.9 PROJECT MANAGEMENT TOOLS AND TECHNIQUES Project management tools and techniques assist project managers and their teams in carrying out work in all nine knowledge areas. For example, some popular time management tools and techniques include Gantt charts, project network diagrams, and critical path analysis. Table 1-1 lists some commonly used tools and techniques by knowledge area. Knowledge area/category Tools and techniques Integration management Scope management Project selection methods, project management methodologies, stakeholder analyses, project charters, project management plans, project management software, change requests, change control boards, project review meetings, lessons-learned reports Scope statements, work breakdown structures, statements of work, requirements analyses, scope management plans, scope verification techniques, and scope change controls Gantt charts, project network diagrams, critical Time management Cost management Quality management Human resource management path analysis, crashing, fast tracking, schedule performance measurements Net present value, return on investment, payback analysis, earned value management, project portfolio management, cost estimates, cost management plans, cost baselines Quality metrics, checklists, quality control charts, Pareto diagrams, fishbone diagrams, maturity models, statistical methods Motivation techniques, empathic listening, responsibility assignment matrices, project organizational charts, resource histograms, team building exercises 20

21 Communications management Risk management Procurement management Communications management plans, kick-off meetings, conflict management, communications media selection, status and progress reports, virtual communications, templates, project Web sites Risk management plans, risk registers, probability/ impact matrices, risk rankings Make-or-buy analyses, contracts, requests for proposals or quotes, source selections, supplier evaluation matrices Knowledge area/category Tools and techniques 1.10 SUMMARY A project is a temporary endeavour undertaken to create a unique product, service, or result. An information technology project involves the use of hardware, software, and/or networks. Projects are unique, temporary, and developed incrementally; they require resources, have a sponsor, and involve uncertainty. The triple constraint of project management refers to managing the scope, time, and cost dimensions of a project. Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Stakeholders are the people involved in or affected by project activities. A framework for project management includes the project stakeholders, project management knowledge areas, and project management tools and techniques. There are many tools and techniques in each knowledge area. There are different ways to define project success, and project managers must understand the success criteria for their unique projects KEYWORDS Project management, Stakeholders, Triple constraint, Project life cycle, Feasibility study, Costbenefit analysis, Software tools, Framework QUESTIONS 21

22 1. What is a project, and what are its main attributes? 2. How is a project different from what most people do in their day-to-day jobs? Discuss. 3. What is the triple constraint? Explain. 4. What is project management? Briefly describe the project management framework, providing examples of stakeholders, knowledge areas, tools and techniques, and project success factors. 5. What is the role of the project manager? 6. What functions can you perform with project management software? 7. What are some popular names of low-end, midrange, and high-end project management tools? 1.13 EXERCISE 1. Search the Internet for the terms project management, project management careers, project portfolio management, and information technology project management. Write down the number of hits that you received for each of these phrases. Find at least three Web sites that provide interesting information on one of the topics. Write a two-page paper summarizing key information about these three Web sites as well as the Project Management Institute s Web site ( 2. Find any example of a real project with a real project manager. Feel free to use projects in the media (the Olympics, television shows, movies, etc.) or a project from your work, if applicable. Write a two-page paper describing the project in terms of its scope, time, and cost goals. Discuss what went right and wrong on the project and the role of the project manager and sponsor. Also describe if the project was a success or not and why REFERENCE 1. Information Technology Project Management: Kathy Schwalbe, International Student Edition, Thomson Course Technology, Software Project Management: Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill. 3. Basics of Software Project Management: NIIT, Prentice-Hall of India, Software Project Management in Practice: Pankaj Jalote, Pearson Education,

23 5. Software Project Management A Concise Study: S.A.Kelkar, Revised Edition, Prentice- Hall of India, Microsoft Office Project 2003 Bible: Elaine Marmel, Wiley Publishing Inc. 23

24 UNIT 2 PROJECT PLANNING STRUCTURE 2.0 Objectives 2.1 Introduction 2.2 Integration Management 2.3 Strategic Planning and Project Selection 2.4 Developing a Project Management Plan 2.5 Directing and Managing Project Execution 2.6 Monitoring and Controlling Project Work 2.7 Performing Integrated Change Control 2.8 Closing Projects or Phases 2.9 Softwares to assist in Project Integration Management 2.10 Summary 2.11 Keywords 2.12 Questions 2.13 Exercise 2.14 Reference 2.0 OBJECTIVES After studying this unit, you will be able to: Describe an overall framework for project integration management. Explain the strategic planning process and apply different project selection methods. Explain the importance of creating a project charter to formally initiate projects. Describe project management plan development, understand the content of these plans, and review approaches for creating them. 24

25 Explain project execution, its relationship to project planning, the factors related to successful results, and tools and techniques to assist in managing project execution. Describe the process of monitoring and controlling a project. Understand the integrated change control process, planning for and managing changes on information technology projects, and developing and using a change control system. Explain the importance of developing and following good procedures for closing projects. Describe how software can assist in project integration management. 2.1 INTRODUCTION All the projects that should be managed by a project manager should have a project plan. The project plan details many aspects of the project to be executed. First of all, it details out the project scope. Then, it describes the approach or strategy used for addressing the project scope and project objectives. The strategy is the core of the project plan and it could vary depending on the project purpose and specific project requirements. The resource allocation and delivery schedule are other two main components of the project plan. These detail each activity involved in the project as well as the information such as who executes them and when. This is important information for the project manager as well as all the other stakeholders of the project. 2.2 INTEGRATION MANAGEMENT Project integration management involves coordinating all of the other project management knowledge areas throughout a project s life cycle. This integration ensures that all the elements of a project come together at the right times to complete a project successfully. There are six main processes involved in project integration management: 1. Developing the project charter involves working with stakeholders to create the document that formally authorizes a project the charter. 2. Developing the project management plan involves coordinating all planning efforts to create a consistent, coherent document the project management plan. 3. Directing and managing project execution involves carrying out the project management plan by performing the activities included in it. The outputs of this process are deliverables, work 25

26 performance information, change requests, project management plan updates, and project document updates. 4. Monitoring and controlling project work involves overseeing activities to meet the performance objectives of the project. The outputs of this process are change requests, project management plan updates, and project document updates. 5. Performing integrated change control involves identifying, evaluating, and managing changes throughout the project life cycle. The outputs of this process include change request status updates, project management plan updates, and project document updates. 6. Closing the project or phase involves finalizing all activities to formally close the project or phrase. Outputs of this process include final product, service, or result transition and organizational process assets updates. Figure 2-1 summarizes these processes and outputs, showing when they occur in a typical project. FIGURE 2-1 Project integration management summary Good project integration management is critical to providing stakeholder satisfaction. Project integration management includes interface management. Interface management involves identifying and managing the points of interaction between various elements of the project. The number of interfaces can increase exponentially as the number of people involved in a project 26

27 increases. Thus, one of the most important jobs of a project manager is to establish and maintain good communication and relationships across organizational interfaces. The project manager must communicate well with all project stakeholders, including customers, the project team, top management, other project managers, and opponents of the project. 2.3 STRATEGIC PLANNING AND PROJECT SELECTION Successful leaders look at the big picture or strategic plan of the organization to determine what types of projects will provide the most value. Some may argue that project managers should not be involved in strategic planning and project selection because top management is usually responsible for these types of business decisions. But successful organizations know that project managers can provide valuable insight into the project selection process. Strategic Planning Strategic planning involves determining long-term objectives by analyzing the strengths and weaknesses of an organization, studying opportunities and threats in the business environment, predicting future trends, and projecting the need for new products and services. Strategic planning provides important information to help organizations identify and then select potential projects. Many people are familiar with SWOT analysis analyzing Strengths, Weaknesses, Opportunities, and Threats which is used to aid in strategic planning. For example, a group of four people who want to start a new business in the film industry could perform a SWOT analysis to help identify potential projects. They might determine the following based on a SWOT analysis: Strengths: As experienced professionals, we have numerous contacts in the film industry. Two of us have strong sales and interpersonal skills. Two of us have strong technical skills and are familiar with several filmmaking software tools. We all have impressive samples of completed projects. Weaknesses: None of us have accounting/financial experience. 27

28 We have no clear marketing strategy for products and services. We have little money to invest in new projects. We have no company Web site and limited use of technology to run the business. Opportunities: A current client has mentioned a large project she would like us to bid on. The film industry continues to grow. There are two major conferences this year where we could promote our company. Threats: Other individuals or companies can provide the services we can. Customers might prefer working with more established individuals/ organizations. There is high risk in the film business. Identifying Potential Projects The first step in project management is deciding what projects to do in the first place. Therefore, project initiation starts with identifying potential projects, using realistic methods to select which projects to work on, and then formalizing their initiation by issuing some sort of project charter. In addition to using a SWOT analysis, organizations often follow a detailed process for project selection. Figure 2-2 shows a four-stage planning process for selecting information technology projects. Note the hierarchical structure of this model and the results produced from each stage. The first step in this process, starting at the top of the hierarchy, is to tie the information technology strategic plan to the organization s overall strategic plan. It is very important to have managers from outside the information technology department assist in the information technology planning process, as they can help information technology personnel understand organizational strategies and identify the business areas that support them. 28

29 FIGURE 2-2 Planning process for selecting information technology projects After identifying strategic goals, the next step in the planning process for selecting information technology projects is to perform a business area analysis. This analysis outlines business processes that are central to achieving strategic goals and helps determine which ones could most benefit from information technology. The next step is to start defining potential information technology projects, their scope, benefits, and constraints. The last step in the planning process for selecting information technology projects is choosing which projects to do and assigning resources for working on them. Methods for Selecting Projects Organizations identify many potential projects as part of their strategic planning processes, and they often rely on experienced project managers to help them make project selection decisions. However, organizations need to narrow down the list of potential projects to those projects that will be of most benefit. Selecting projects is not an exact science, but it is a necessary part of project management. Many methods exist for selecting from among possible projects. Five common techniques are: Focusing on broad organizational needs Categorizing information technology projects Performing net present value or other financial analyses Using a weighted scoring model 29

30 Implementing a balanced scorecard In practice, organizations usually use a combination of these approaches to select projects. Each approach has advantages and disadvantages, and it is up to management to decide the best approach for selecting projects based on their particular organization. Focusing on Broad Organizational Needs Top managers must focus on meeting their organization s many needs when deciding what projects to undertake, when to undertake them, and to what level. Projects that address broad organizational needs are much more likely to be successful because they will be important to the organization. For example, a broad organizational need might be to improve safety, increase morale, provide better communications, or improve customer service. However, it is often difficult to provide a strong justification for many information technology projects related to these broad organizational needs. For example, it is often impossible to estimate the financial value of such projects, but everyone agrees that they do have a high value. One method for selecting projects based on broad organizational needs is to determine whether they first meet three important criteria: need, funding, and will. Do people in the organization agree that the project needs to be done? Does the organization have the desire and the capacity to provide adequate funds to perform the project? Is there a strong will to make the project succeed? For example, many visionary CEOs can describe a broad need to improve certain aspects of their organizations, such as communications. Although they cannot specifically describe how to improve communications, they might allocate funds to projects that address this need. As projects progress, the organization must re-evaluate the need, funding, and will for each project to determine if the project should be continued, redefined, or terminated. Categorizing Information Technology Projects Another method for selecting projects is based on various categorizations, such as the impetus for the project, the time window for the project, and the general priority for the project. The impetus for a project is often to respond to a problem, an opportunity, or a directive. Problems are undesirable situations that prevent an organization from achieving its goals. These problems can be current or anticipated. For example, users of an information system may be having trouble logging onto the system or getting information in a timely manner because the system has reached its capacity. In response, the company could initiate a 30

31 project to enhance the current system by adding more access lines or upgrading the hardware with a faster processor, more memory, or more storage space. Opportunities are chances to improve the organization. For example, the project described in the opening case involves creating a new product that can make or break the entire company. Directives are new requirements imposed by management, government, or some external influence. For example, many projects involving medical technologies must meet rigorous government requirements. Organizations select projects for any of these reasons. It is often easier to get approval and funding for projects that address problems or directives because the organization must respond to these categories of projects to avoid hurting their business. Many problems and directives must be resolved quickly, but managers must also apply systems thinking and seek opportunities for improving the organization through information technology projects. Another categorization for information technology projects is based on the time it will take to complete a project or the date by which it must be done. For example, some potential projects must be finished within a specific time window. If they cannot be finished by this set date, they are no longer valid projects. Some projects can be completed very quickly within a few weeks, days, or even minutes. Many organizations have an end user support function to handle very small projects that can be completed quickly. Even though many information technology projects can be completed quickly, it is still important to prioritize them. Organizations can also prioritize information technology projects as being high-, medium-, or low-priority based on the current business environment. For example, if it is crucial to cut operating costs quickly, projects that have the most potential to do so would be given a high priority. The organization should always complete high-priority projects first, even if a low- or medium-priority project could be finished in less time. Usually there are many more potential information technology projects than an organization can undertake at any one time, so it is very important to work on the most important ones first. Performing Net Present Value Analysis, Return on Investment, and Payback Analysis Financial considerations are often an important aspect of the project selection process, especially during tough economic times. Many organizations require an approved business case before 31

32 pursuing projects, and financial projections are a critical component of the business case. Three primary methods for determining the projected financial value of projects include net present value analysis, return on investment, and payback analysis. Because project managers often deal with business executives, they must understand how to speak their language, which often boils down to these important financial concepts. Net Present Value Analysis: Everyone knows that a dollar earned today is worth more than a dollar earned five years from now. Net present value (NPV) analysis is a method of calculating the expected net monetary gain or loss from a project by discounting all expected future cash inflows and outflows to the present point in time. An organization should consider only projects with a positive NPV if financial value is a key criterion for project selection. This is because a positive NPV means the return from a project exceeds the cost of capital the return available by investing the capital elsewhere. Projects with higher NPVs are preferred to projects with lower NPVs, if all other factors are equal. Return on Investment: Another important financial consideration is return on investment. Return on investment (ROI) is the result of subtracting the project costs from the benefits and then dividing by the costs. For example, if you invest Rs.100 today and next year it is worth Rs.110, your ROI is (Rs )/100 or 0.10 (10 percent). Note that the ROI is always a percentage. It can be positive or negative. It is best to consider discounted costs and benefits for multi-year projects when calculating ROI. Payback Analysis: Payback analysis is another important financial tool to use when selecting projects. Payback period is the amount of time it will take to recoup, in the form of net cash inflows, the total dollars invested in a project. In other words, payback analysis determines how much time will lapse before accrued benefits overtake accrued and continuing costs. Payback occurs when the net cumulative benefits equal the net cumulative costs, or when the net cumulative benefits minus costs equals zero. Using a Weighted Scoring Model A weighted scoring model is a tool that provides a systematic process for selecting projects based on many criteria. These criteria can include factors such as meeting broad organizational needs; addressing problems, opportunities, or directives; the amount of time it will take to 32

33 complete the project; the overall priority of the project; and projected financial performance of the project. The first step in creating a weighted scoring model is to identify criteria important to the project selection process. It often takes time to develop and reach agreement on these criteria. Holding facilitated brainstorming sessions or using groupware to exchange ideas can aid in developing these criteria. Some possible criteria for information technology projects include: Supports key business objectives Has strong internal sponsor Has strong customer support Uses realistic level of technology Can be implemented in one year or less Provides positive NPV Has low risk in meeting scope, time, and cost goals Implementing a Balanced Scorecard A balanced scorecard is a methodology that converts an organization s value drivers, such as customer service, innovation, operational efficiency, and financial performance, to a series of defined metrics. Organizations record and analyze these metrics to determine how well projects help them achieve strategic goals. Developing a Project Charter After top management decides on which projects to pursue, it is important to let the rest of the organization know about these projects. Management needs to create and distribute documentation to authorize project initiation. This documentation can take many different forms, but one common form is a project charter. A project charter is a document that formally recognizes the existence of a project and provides direction on the project s objectives and management. It authorizes the project manager to use organizational resources to complete the project. Ideally, the project manager will provide a major role in developing the project charter. Instead of project charters, some organizations initiate projects using a simple letter of agreement, while others use much longer documents or formal contracts. Key project stakeholders should sign a project charter to acknowledge agreement on the need for and intent of the project. 33

34 Inputs that are helpful in developing a project charter include the following: A project statement of work: A statement of work is a document that describes the products or services to be created by the project team. It usually includes a description of the business need for the project, a summary of the requirements and characteristics of the products or services, and organizational information, such as appropriate parts of the strategic plan, showing the alignment of the project with strategic goals. A business case: Many projects require a business case to justify their investment. Information in the business case, such as the project objective, high-level requirements, and time and cost goals are included in the project charter. A contract: If you are working on a project under contract for an external customer, the contract should include much of the information needed for creating a good project charter. Some people might use a contract in place of a charter; however, many contracts are difficult to read and can often change, so it is still a good idea to create a project charter. Enterprise environmental factors: These factors include relevant government or industry standards, the organization s infrastructure, and marketplace conditions. Managers should review these factors when developing a project charter. Organizational process assets: Organizational process assets include formal and informal plans, policies, procedures, guidelines, information systems, financial systems, management systems, lessons learned, and historical information that can be used to influence a project s success. The main tool and technique for developing a project charter is expert judgment. Experts from within as well as outside the organization should be consulted when creating a project charter to make sure it is useful and realistic. The only output of the process to develop a project charter is a project charter. Although the format of project charters can vary tremendously, they should include at least the following basic information: The project s title and date of authorization. The project manager s name and contact information. A summary schedule, including the planned start and finish dates; if a summary milestone schedule is available, it should also be included or referenced. 34

35 A summary of the project s budget or reference to budgetary documents. A brief description of the project objectives, including the business need or other justification for authorizing the project. Project success criteria, including project approval requirements and who signs off on the project. A summary of the planned approach for managing the project, which should describe stakeholder needs and expectations, important assumptions, and constraints, and refer to related documents, such as a communications management plan, as available. A roles and responsibilities matrix. A sign-off section for signatures of key project stakeholders. A comments section in which stakeholders can provide important comments related to the project. 2.4 DEVELOPING A PROJECT MANAGEMENT PLAN To coordinate and integrate information across project management knowledge areas and across the organization, there must be a good project management plan. A project management plan is a document used to coordinate all project planning documents and help guide a project s execution and control. Plans created in the other knowledge areas are considered subsidiary parts of the overall project management plan. Project management plans also document project planning assumptions and decisions regarding choices, facilitate communication among stakeholders, define the content, extent, and timing of key management reviews, and provide a baseline for progress measurement and project control. Project management plans should be dynamic, flexible, and subject to change when the environment or project changes. These plans should greatly assist the project manager in leading the project team and assessing project status. To create and assemble a good project management plan, the project manager must practice the art of project integration management, since information is required from all of the project management knowledge areas. Working with the project team and other stakeholders to create a project management plan will help the project manager guide the project s execution and understand the overall project. The main inputs for developing a project management plan include the project charter, outputs from planning processes, enterprise environment factors, and 35

36 organizational process assets. The main tool and technique is expert judgment, and the output is a project management plan. Project Management Plan Contents Just as projects are unique, so are project management plans. A small project involving a few people over a couple of months might have a project management plan consisting of only a project charter, scope statement, and Gantt chart. A large project involving a hundred people over three years would have a much more detailed project management plan. It is important to tailor project management plans to fit the needs of specific projects. The project management plans should guide the work, so they should be only as detailed as needed for each project. There are, however, common elements to most project management plans. Parts of a project management plan include an introduction or overview of the project, a description of how the project is organized, the management and technical processes used on the project, and sections describing the work to be performed, the schedule, and the budget. The introduction or overview of the project should include, as a minimum, the following information: The project name: Every project should have a unique name. Unique names help distinguish each project and avoid confusion among related projects. A brief description of the project and the need it addresses: This description should clearly outline the goals of the project and reason for the project. It should be written in layperson s terms, avoid technical jargon, and include a rough time and cost estimate. The sponsor s name: Every project needs a sponsor. Include the name, title, and contact information of the sponsor in the introduction. The names of the project manager and key team members: The project manager should always be the contact for project information. Depending on the size and nature of the project, names of key team members may also be included. Deliverables of the project: This section should briefly list and describe the products that will be produced as part of the project. Software packages, pieces of hardware, technical reports, and training materials are examples of deliverables. A list of important reference materials: Many projects have a history preceding them. Listing important documents or meetings related to a project helps project stakeholders understand that history. This section should reference the plans produced for other 36

37 knowledge areas. Therefore, the project management plan should reference and summarize important parts of the scope management, schedule management, cost management, quality management, human resource management, communications management, risk management, and procurement management plans. A list of definitions and acronyms, if appropriate: Many projects, especially information technology projects, involve terminology unique to a particular industry or technology. Providing a list of definitions and acronyms will help avoid confusion. The description of how the project is organized should include the following information: Organizational charts: In addition to an organizational chart for the company sponsoring the project and for the customer s company (if it is an external customer), there should be a project organizational chart to show the lines of authority, responsibilities, and communication for the project. Project responsibilities: This section of the project plan should describe the major project functions and activities and identify those individuals who are responsible for them. Other organizational or process-related information: Depending on the nature of the project, there may be a need to document major processes followed on the project. For example, if the project involves releasing a major software upgrade, it might help everyone involved in the project to see a diagram or timeline of the major steps involved in this process. The section of the project management plan describing management and technical approaches should include the following information: Management objectives: It is important to understand top management s view of the project, what the priorities are for the project, and any major assumptions or constraints. Project controls: This section describes how to monitor project progress and handle changes. Will there be monthly status reviews and quarterly progress reviews? Will there be specific forms or charts to monitor progress? Will the project use earned value management to assess and track performance? What is the process for change control? What level of management is required to approve different types of changes? 37

38 Risk management: This section briefly addresses how the project team will identify, manage, and control risks. It should refer to the risk management plan, if one is required for the project. Project staffing: This section describes the number and types of people required for the project. It should refer to the human resource plan, if one is required for the project. Technical processes: This section describes specific methodologies a project might use and explains how to document information. For example, many information technology projects follow specific software development methodologies or use particular Computer Aided Software Engineering (CASE) tools. Many companies or customers also have specific formats for technical documentation. It is important to clarify these technical processes in the project management plan. The next section of the project management plan should describe the work to perform and reference the scope management plan. It should summarize the following: Major work packages: A project manager usually organizes the project work into several work packages using a work breakdown structure (WBS), and produces a scope statement to describe the work in more detail. This section should briefly summarize the main work packages for the project and refer to appropriate sections of the scope management plan. Key deliverables: This section lists and describes the key products produced as part of the project. It should also describe the quality expectations for the product deliverables. Other work-related information: This section highlights key information related to the work performed on the project. For example, it might list specific hardware or software to use on the project or certain specifications to follow. It should document major assumptions made in defining the project work. The project schedule information section should include the following: Summary schedule: It is helpful to see a one-page summary of the overall project schedule. Depending on the size and complexity of the project, the summary schedule might list only key deliverables and their planned completion dates. For smaller projects, it might include all of the work and associated dates for the entire project in a Gantt chart. Detailed schedule: This section provides information on the project schedule that is more detailed. It should reference the schedule management plan and discuss dependencies 38

39 among project activities that could affect the project schedule. For example, it might explain that a major part of the work cannot start until an external agency provides funding. A network diagram can show these dependencies. Other schedule-related information: Many assumptions are often made in preparing project schedules. This section should document major assumptions and highlight other important information related to the project schedule. The budget section of the project management plan should include the following: Summary budget: The summary budget includes the total estimate of the overall project s budget. It could also include the budget estimate for each month or year by certain budget categories. It is important to provide some explanation of what these numbers mean. For example, is the total budget estimate a firm number that cannot change, or is it a rough estimate based on projected costs over the next three years? Detailed budget: This section summarizes what is in the cost management plan and includes more detailed budget information. For example, what are the fixed and recurring cost estimates for the project each year? What are the projected financial benefits of the project? What types of people are needed to do the work, and how are the labour costs calculated? Other budget-related information: This section documents major assumptions and highlights other important information related to financial aspects of the project. Using Guidelines to Create Project Management Plans Many organizations use guidelines to create project management plans. Microsoft Project 2007 and other project management software packages come with several template files to use as guidelines. Many government agencies also provide guidelines for creating project management plans. For example, the U.S. Department of Defence (DOD) Standard 2167, Software Development Plan, describes the format for contractors to use in creating a plan for software development for DOD projects. The Institute of Electrical and Electronics Engineers (IEEE) Standard describes the contents of a Software Project Management Plan (SPMP). Table 2-1 provides some of the categories for the IEEE SPMP. Companies working on software development projects for the Department of Defence must follow this or a similar standard. TABLE 2-1 Sample contents for a software project management plan (SPMP) 39

40 In many private organizations, specific documentation standards are not as rigorous; however, there are usually guidelines for developing project management plans. It is good practice to follow standards or guidelines for developing project management plans in an organization to facilitate the development and execution of those plans. The organization can work more efficiently if all project management plans follow a similar format. 2.5 DIRECTING AND MANAGING PROJECT EXECUTION Directing and managing project execution involves managing and performing the work described in the project management plan, one of the main inputs for this process. Other inputs include approved change requests, enterprise environmental factors, and organizational process assets. The majority of time on a project is usually spent on execution, as is most of the project s budget. The application area of the project directly affects project execution because the products of the project are produced during project execution. The project manager would also need to focus on leading the project team and managing stakeholder relationships to execute the project management plan successfully. Project human resource management and project communications management are crucial to a project s success. 40

41 Coordinating Planning and Execution In project integration management, project planning and execution are intertwined and inseparable activities. The main function of creating a project management plan is to guide project execution. A good plan should help produce good products or work results. Plans should document what good work results consist of. Updates to plans should reflect knowledge gained from completing work earlier in the project. Anyone who has tried to write a computer program from poor specifications appreciates the importance of a good plan. Anyone who has had to document a poorly programmed system appreciates the importance of good execution. Providing Strong Leadership and a Supportive Culture Strong leadership and a supportive organizational culture are crucial during project execution. Project managers must lead by example to demonstrate the importance of creating good project plans and then following them in project execution. Project managers often create plans for things they need to do themselves. If project managers follow through on their own plans, their team members are more likely to do the same. Good project execution also requires a supportive organizational culture. For example, organizational procedures can help or hinder project execution. If an organization has useful guidelines and templates for project management that everyone in the organization follows, it will be easier for project managers and their teams to plan and do their work. If the organization uses the project plans as the basis for performing and monitoring progress during execution, the culture will promote the relationship between good planning and execution. On the other hand, if organizations have confusing or bureaucratic project management guidelines that hinder getting work done or measuring progress against plans, project managers and their teams will be frustrated. Project Execution Tools and Techniques Directing and managing project execution requires specialized tools and techniques, some of which are unique to project management. Project managers can use specific tools and techniques to perform activities that are part of execution processes. These include: Expert judgment: Anyone who has worked on a large, complex project appreciates the importance of expert judgment in making good decisions. Project managers should not 41

42 hesitate to consult experts on different topics, such as what methodology to follow, what programming language to use, what training approach to follow, and so on. Project management information systems: There are hundreds of project management software products on the market today. Many large organizations use powerful enterprise project management systems that are accessible via the Internet and tie into other systems, such as financial systems. Even in smaller organizations, project managers or other team members can create Gantt charts that include links to other planning documents on an internal network. 2.6 MONITORING AND CONTROLLING PROJECT WORK On large projects, many project managers say that 90 percent of the job is communicating and managing changes. Changes are inevitable on most projects, so it s important to develop and follow a process to monitor and control changes. Monitoring project work includes collecting, measuring, and disseminating performance information. It also involves assessing measurements and analyzing trends to determine what process improvements can be made. The project team should continuously monitor project performance to assess the overall health of the project and identify areas that require special attention. The project management plan, performance reports, enterprise environmental factors, and organizational process assets are all important inputs for monitoring and controlling project work. The project management plan provides the baseline for identifying and controlling project changes. A baseline is the approved project management plan plus approved changes. For example, the project management plan includes a section describing the work to perform on a project. This section of the plan describes the key deliverables for the project, the products of the project, and quality requirements. The schedule section of the project management plan lists the planned dates for completing key deliverables, and the budget section of the project management plan provides the planned cost for these deliverables. The project team must focus on delivering the work as planned. If the project team or someone else causes changes during project execution, they must revise the project management plan and have it approved by the project sponsor. Many people refer to different types of baselines, such as a cost baseline or schedule baseline, to describe different project goals more clearly and performance toward meeting them. 42

43 Performance reports use this data to provide information on how project execution is going. The main purpose of these reports is to alert the project manager and project team of issues that are causing problems or might cause problems in the future. The project manager and project team must continuously monitor and control project work to decide if corrective or preventive actions are needed, what the best course of action is, and when to act. An important output of monitoring and controlling project work is a change request, which includes recommended corrective and preventive actions and defect repairs. Corrective actions should result in improvements in project performance. Preventive actions reduce the probability of negative consequences associated with project risks. Defect repairs involve bringing defective deliverables into conformance with requirements. For example, if project team members have not been reporting hours that they worked, a corrective action would be to show them how to enter the information and let them know that they need to do it. A preventive action might be modifying a time-tracking system screen to avoid common errors people made in the past. A defect repair might be having someone redo an entry that was incorrect. 2.7 PERFORMING INTEGRATED CHANGE CONTROL Integrated change control involves identifying, evaluating, and managing changes throughout the project life cycle. The three main objectives of integrated change control are: Influencing the factors that create changes to ensure that changes are beneficial: To ensure that changes are beneficial and that a project is successful, project managers and their teams must make trade-offs among key project dimensions, such as scope, time, cost, and quality. Determining that a change has occurred: To determine that a change has occurred, the project manager must know the status of key project areas at all times. In addition, the project manager must communicate significant changes to top management and key stakeholders. Top management and other key stakeholders do not like surprises, especially ones that mean the project might produce less, take longer to complete, cost more than planned, or be of lower quality than desired. 43

44 Managing actual changes as they occur: Managing change is a key role of project managers and their teams. It is important that project managers exercise discipline in managing the project to help minimize the number of changes that occur. Table 2-2 lists suggestions for performing integrated change control. As described earlier, project management is a process of constant communication and negotiation. Project managers should plan for changes and use appropriate tools and techniques such as a change control board, configuration management, and good communication. It is helpful to define procedures for making timely decisions on small changes, use written and oral performance reports to help identify and manage changes, and use software to assist in planning, updating, and controlling projects. TABLE 2-2 Suggestions for performing integrated change control Project managers must also provide strong leadership to steer the project to successful completion. They must not get too involved in managing project changes. Project managers should delegate much of the detailed work to project team members and focus on providing overall leadership for the project in general. Remember, project managers must focus on the big picture and perform project integration management well to lead their team and organization to success. 44

45 2.8 CLOSING PROJECTS OR PHASES The last process in project integration management is closing the project or phase. In order to close a project or phase, you must finalize all activities and transfer the completed or cancelled work to the appropriate people. The main inputs to this process are the project management plan, accepted deliverables, and organizational process assets. The main tool and technique is again expert judgment. The outputs of closing projects are: Final product, service, or result transition: Project sponsors are usually most interested in making sure they receive delivery of the final products, services, or results they expected when they authorized the project. For items produced under contract, formal acceptance or handover includes a written statement that the terms of the contract were met. Internal projects can also include some type of project completion form. Organizational process asset updates: The project team should provide a list of project documentation, project closure documents, and historical information produced by the project in a useful format. This information is considered a process asset. Project teams normally produce a final project report, which often includes a transition plan describing work to be done as part of operations after the project is completed. They also often write a lessons-learned report at the end of a project, and this information can be a tremendous asset for future projects. Several organizations also conduct a post implementation review to analyze whether or not the project achieved what it set out to do. Information from this type of review also becomes an organizational process asset for future projects. 2.9 SOFTWARE TO ASSIST IN PROJECT INTEGRATION MANAGEMENT Project teams can use various types of software to assist in project integration management. Project teams can create documents with word processing software, give presentations with presentation software, track information with spreadsheets, databases, or customized software, and transmit information using various types of communication software. Project management software is also an important tool for developing and integrating project planning documents, executing the project management plan and related project plans, monitoring and controlling project activities, and performing integrated change control. Small 45

46 project teams can use low-end or midrange project management software products to coordinate their work. For large projects, however, such as managing the Olympic Games described in the Media Snapshot, organizations may benefit most from high-end tools that provide enterprise project management capabilities and integrate all aspects of project management. All projects can benefit from using some type of project management information system to coordinate and communicate project information SUMMARY Project integration management is usually the most important project management knowledge area, since it ties together all the other areas of project management. A project manager s primary focus should be on project integration management. Before selecting projects to pursue, it is important for organizations to follow a strategic planning process. Many organizations perform a SWOT analysis to help identify potential projects based on their strengths, weaknesses, opportunities, and threats. Information technology projects should support the organization s overall business strategy. Common techniques for selecting projects include focusing on broad organizational needs, categorizing projects, performing financial analyses, developing weighted scoring models, and using balanced scorecards. There are several types of software products available to assist in project integration management. There are also several tools to assist in project selection and to ensure that projects align with business strategy KEYWORDS Balanced scorecard, baseline, integrated change control, interface management, net present value, payback period, return on investment, SWOT analysis, weighted scoring model QUESTIONS 1. Describe project integration management. How does project integration management relate to the project life cycle, stakeholders, and the other project management knowledge areas? 46

47 2. Briefly describe the strategic planning process, including a SWOT analysis. 3. Which project selection method(s) do you think organizations use most often for justifying information technology projects? 4. Summarize key work involved in each of the six processes for project integration management. 5. Either from your own experience or by searching the Internet, describe a well-planned and executed project. Describe a disastrous project. What were some of the main differences between these projects? 6. Discuss the importance of following a well-integrated change control process on information technology projects EXERCISE 1. Develop an outline (major headings and subheadings only) for a project management plan to create a Web site for your class, and then fill in the details for the introduction or overview section. Assume that this Web site would include a home page with links to a syllabus for the class, lecture notes or other instructional information, links to the Web site for this textbook, links to other Web sites with project management information, and links to personal pages for each member of your class and future classes. Also, include a bulletin board and chat room feature where students and the instructor can exchange information. Assume your instructor is the project s sponsor, you are the project manager, your classmates are your project team, and you have three months to complete the project REFERENCE 1. Information Technology Project Management: Kathy Schwalbe, International Student Edition, Thomson Course Technology, Software Project Management: Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill. 3. Basics of Software Project Management: NIIT, Prentice-Hall of India, Software Project Management in Practice: Pankaj Jalote, Pearson Education, Software Project Management A Concise Study: S.A.Kelkar, Revised Edition, Prentice- Hall of India, Microsoft Office Project 2003 Bible: Elaine Marmel, Wiley Publishing Inc. 47

48 UNIT 3 PROJECT SCOPE MANAGEMENT STRUCTURE 3.0 Objectives 3.1 Introduction 3.2 Project Scope Management 3.3 Collecting Requirements 3.4 Defining Scope 3.5 Creating the Work Breakdown Structures 3.6 Verifying Scope 3.7 Controlling Scope 3.8 Softwares to assist in Project Scope Management 3.9 Summary 3.10 Keywords 3.11 Questions 3.12 Exercise 3.13 Reference 3.0 OBJECTIVES After studying this unit, you will be able to: Explain the importance of good project scope management. Discuss methods for collecting and documenting requirements in order to meet stakeholder needs and expectations. Explain the scope definition process and describe the contents of a project scope statement. Discuss the process for creating a work breakdown structure using the analogy, topdown, bottom-up, and mind-mapping approaches. 48

49 Explain the importance of verifying scope and how it relates to defining and controlling scope. Discuss the importance of controlling scope and approaches for preventing scope-related problems on information technology projects. Describe how software can assist in project scope management. 3.1 INTRODUCTION Success of any software project depends on several factors. Many of these factors, such as user involvement, clear business objectives, a minimized or clearly defined scope, and firm basic requirements, are elements of project scope management. One of the most important and most difficult aspects of project management is defining the scope of a project. Scope refers to all the work involved in creating the products of the project and the processes used to create them. The term deliverable describes a product produced as part of a project. Deliverables can be productrelated, such as a piece of hardware or software, or process-related, such as a planning document or meeting minutes. Project stakeholders must agree on what the products of the project are and, to some extent, how they should produce them to define all of the deliverables. 3.2 PROJECT SCOPE MANAGEMENT Project scope management includes the processes involved in defining and controlling what work is or is not included in a project. It ensures that the project team and stakeholders have the same understanding of what products the project will produce and what processes the project team will use to produce them. There are five main processes involved in project scope management: Collecting requirements involves defining and documenting the features and functions of the products produced during the project as well as the processes used for creating them. The project team creates stakeholder requirements documentation, a requirements management plan, and a requirements traceability matrix as outputs of the requirements collection process. 49

50 Defining scope involves reviewing the project charter, requirements documents, and organizational process assets to create a scope statement, adding more information as requirements are developed and change requests are approved. The main outputs of scope definition are the project scope statement and updates to project documents. Creating the WBS involves subdividing the major project deliverables into smaller, more manageable components. The main outputs include a work breakdown structure, a WBS dictionary, a scope baseline, and updates to project documents. Verifying scope involves formalizing acceptance of the project deliverables. Key project stakeholders, such as the customer and sponsor for the project, inspect and then formally accept the deliverables during this process. If the deliverables are not acceptable, the customer or sponsor usually requests changes. The main outputs of this process, therefore, are accepted deliverables and change requests. Controlling scope involves controlling changes to project scope throughout the life of the project a challenge on many information technology projects. Scope changes often influence the teams ability to meet project time and cost goals, so project managers must carefully weigh the costs and benefits of scope changes. The main outputs of this process are change requests, work performance measurements, and updates to organizational process assets, the project management plan, and project documents. Figure 3-1 summarizes these processes and outputs and shows when they occur in a typical project. FIGURE 3-1 Project scope management summary 50

51 3.3 COLLECTING REQUIREMENTS The first step and the most difficult in project scope management is collecting requirements. A major consequence of not defining requirements well is rework, which can consume up to half of project costs, especially for software development projects. As illustrated in Figure 3-2, it costs much more to correct a software defect that is found in later development phases than to fix it in the requirements phase. Part of the difficulty is that people often don t have a consistent definition of what requirements are, how to collect them, and how to document them. What are Requirements? The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as follows: 1. A condition or capability needed by a user to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. 3. A documented representation of a condition or capability as in 1 or 2. It is important to document requirements in enough detail so that they can be measured during project execution. After all, meeting scope goals is often based on meeting documented requirements. For example, the opening case describes a project for upgrading IT assets to meet corporate standards. It says that these standards specify the minimum equipment required for each desktop or laptop computer, such as the type of processor, amount of memory, and hard disk size. The documented requirements for this project might include, therefore, that all computers include an Intel processor, 4GB of memory, and a 160GB hard drive. For some IT projects, it is helpful to divide requirements development into categories called elicitation, analysis, specification, and validation. These categories include all the activities involved in gathering, evaluating, and documenting requirements for a software or softwarecontaining product. It is also important to use an iterative approach to defining requirements since requirements are often unclear early in a project. 51

52 How Do You Collect Requirements? There are several ways to collect requirements. Interviewing stakeholders one-on-one is often very effective, although it can be very expensive and time-consuming. Holding focus groups, facilitated workshops, and using group creativity and decision-making techniques to collect requirements are normally faster and less expensive than one-on-one interviews. Questionnaires and surveys can be very efficient ways to collect requirements as long as key stakeholders provide honest and thorough information. Observation can also be a good technique for collecting requirements, especially for projects that involve improving work processes and procedures. Prototyping is a commonly used technique for collecting requirements for software development projects. There are also several software tools available to assist in collecting and managing requirements. The project s size, complexity, importance, and other factors will affect how much effort is spent on collecting requirements. For example, a team working on a project to upgrade the entire corporate accounting system for a multibillion dollar company with more than 50 geographic locations should spend a fair amount of time collecting requirements. A project to upgrade the hardware and software for a small accounting firm with only five employees, on the other hand, would need a much smaller effort. In any case, it is important for a project team to decide how they will collect and manage requirements. It is crucial to gather inputs from key stakeholders and align the scope, a key aspect of the entire project, with business strategy. How Do You Document Requirements? Just as there are several ways to collect requirements, there are several ways to document them. Project teams should first review the project charter since it includes high-level requirements for the project and may refer to other documents that include requirements. They should also review the stakeholder register to ensure that all key stakeholders have a say in determining requirements. The format for documenting stakeholder requirements can range from a listing of all requirements on a single piece of paper to a room full of notebooks documenting requirements. People who have worked on complex projects, such as building a new airplane, know that the paper documenting requirements for a plane can weigh more than the plane itself! Requirements documents are often generated by software and include text, images, diagrams, videos, and other media. Requirements are also often broken down into different categories such 52

53 as functional requirements, service requirements, performance requirements, quality requirements, training requirements, and so on. In addition to preparing stakeholder requirements documentation as an output of the collecting requirements process, project teams often create a requirements management plan and a requirements traceability matrix. The requirements management plan describes how project requirements will be analyzed, documented, and managed. A requirements traceability matrix (RTM) is a table that lists requirements, various attributes of each requirement, and the status of the requirements to ensure that all requirements are addressed. There are many variations of what can be included in an RTM. For example, software requirements are often documented in an RTM that cross-references each requirement with related ones and lists specific tests to verify that they are met. Remember that the main purpose of an RTM is to maintain the linkage from the source of each requirement through its decomposition to implementation and verification. 3.4 DEFINING SCOPE Good scope definition is very important to project success because it helps improve the accuracy of time, cost, and resource estimates, it defines a baseline for performance measurement and project control, and it aides in communicating clear work responsibilities. The main tools and techniques used in defining scope include expert judgment, product analysis, alternatives identification, and facilitated workshops. The main outputs of scope definition are the project scope statement and project document updates. Key inputs for preparing the project scope statement include the project charter, requirements documentation, and organizational process assets such as policies and procedures related to scope statements as well as project files and lessons learned from previous, similar projects. Information in the project charter provides a basis for further defining the project scope. The charter describes the high-level scope, time, and cost goals for the project objectives and success criteria, a general approach to accomplishing the project s goals, and the main roles and responsibilities of important project stakeholders. Although contents vary, project scope statements should include, at a minimum, a product scope description, product user acceptance criteria, and detailed information on all project deliverables. It is also helpful to document other scope-related information, such as the project boundaries, constraints, and assumptions. The project scope statement should also reference supporting 53

54 documents, such as product specifications that will affect what products are produced or purchased, or corporate policies, which might affect how products or services are produced. Many information technology projects also require detailed functional and design specifications for developing software, which also should be referenced in the detailed scope statement. 3.5 CREATING THE WORK BREAKDOWN STRUCTURES After collecting requirements and defining scope, the next step in project scope management is to create a work breakdown structure. A work breakdown structure (WBS) is a deliverableoriented grouping of the work involved in a project that defines the total scope of the project. Because most projects involve many people and many different deliverables, it is important to organize and divide the work into logical parts based on how the work will be performed. The WBS is a foundation document in project management because it changes. Since the WBS defines the total scope of the project, some project management experts believe that work should not be done on a project if it is not included in the WBS. Therefore, it is crucial to develop a good WBS. The project scope statement, stakeholder requirements documentation, and organizational process assets are the primary inputs for creating a WBS. The main tool or technique is decomposition, which is subdividing project deliverables into smaller pieces. The outputs of the process of creating the WBS are the WBS itself, the WBS dictionary, a scope baseline, and project document updates. What does a WBS look like? A WBS is often depicted as a task-oriented family tree of activities, similar to an organizational chart. A project team often organizes the WBS around project products, project phases, or using the project management process groups. Many people like to create a WBS in chart form first to help them visualize the whole project and all of its main parts. For example, Figure 3-2 shows a WBS for an intranet project. 54

55 FIGURE 3-2 Sample intranet WBS organized by product Notice that product areas provide the basis for its organization. In this case, there are main boxes or groupings on the WBS for developing the Web site design, the home page for the intranet, the marketing department s pages, and the sales department s pages. In contrast, a WBS for the same intranet project can be organized around project phases, as shown in Figure 3-3. Notice that project phases of concept, Web site design, Web site development, roll out, and support provide the basis for its organization. 55

56 FIGURE 3-3 Sample intranet WBS organized by phase in chart and tabular form Also note the levels in Figure 3-3. The name of the entire project is the top box, called Level 1, and the main groupings for the work are listed in the second tier of boxes, called Level 2. This level numbering is based on PMI s Practice Standard for Work Breakdown Structures. Each of those boxes can be broken down into subsequent tiers of boxes to show the hierarchy of the work. PMI uses the term task to describe each level of work in the WBS. For example, in Figure 3-3, the following items can be referred to as tasks: the Level 2 item called Concept, the Level 3 item called Define requirements, and the Level 4 item called Define user requirements. Tasks that are decomposed into smaller tasks are called summary tasks. Figure 3-3 shows a sample WBS in both chart and tabular form. Notice that both of these formats show the same 56

57 information. Many documents, such as contracts, use the tabular format. Project management software also uses this format. The WBS becomes the contents of the Task Name column in Microsoft Project, and the hierarchy or level of tasks is shown by indenting and numbering tasks within the software. The numbering shown in the tabular form on the left in Figure 3-3 coincides with numbering in Microsoft Project and other sources. The numbering shown in the tabular form on the right in Figure 3-3 is based on PMI s Practice Standard for Work Breakdown Structures, Second Edition. In Figure 3-3, the lowest level of the WBS is Level 4. A work package is a task at the lowest level of the WBS. In Figure 3-3, tasks 1.2.1, 1.2.2, 1.2.3, and (based on the numbering on the left) are work packages. The other tasks would probably be broken down further. However, some tasks can remain at Level 2 or 3 in the WBS. Some might be broken down to Level 5 or 6, depending on the complexity of the work. A work package also represents the level of work that the project manager monitors and controls. You can think of work packages in terms of accountability and reporting. If a project has a relatively short time frame and requires weekly progress reports, a work package might represent work completed in one week or less. If a project has a very long time frame and requires quarterly progress reports, a work package might represent work completed in one month or more. A work package might also be the procurement of a specific product or products, such as an item or items purchased from an outside source. Another way to think of work packages relates to entering data into project management software. You can only enter duration estimates for work packages. The rest of the WBS items are just groupings or summary tasks for the work packages. The software automatically calculates duration estimates for various WBS levels based on data entered for each work package and the WBS hierarchy. Figure 3-4 shows the phase-oriented intranet WBS, using the Microsoft Project numbering scheme from Figure 3-3, in the form of a Gantt chart created in Project You can see from this figure that the WBS is the basis for project schedules. Notice that the WBS is in the left part of the figure under the Task Name column. The resulting schedule is in the right part of the figure. 57

58 FIGURE 3-4 Intranet Gantt chart in Microsoft Project The sample WBSs shown here seem somewhat easy to construct and understand. Nevertheless, it is very difficult to create a good WBS. To create a good WBS, you must understand the project and its scope and incorporate the needs and knowledge of the stakeholders. The project manager and the project team must decide as a group how to organize the work and how many levels to include in the WBS. Many project managers have found that it is better to focus on getting the top levels done well before getting too bogged down in more detailed levels. Another concern when creating a WBS is how to organize it so that it provides the basis for the project schedule. You should focus on what work needs to be done and how it will be done, not when it will be done. In other words, the tasks do not have to be developed as a sequential list of steps. If you do want some time-based flow for the work, you can create a WBS using the project management process groups of initiating, planning, executing, monitoring and controlling, and closing as Level 2 in the WBS. By doing this, not only does the project team follow good project management practice, but the WBS tasks can also be mapped more easily against time. For example, Figure 3-5 shows a WBS and Gantt chart for the intranet project, organized by the five project management process groups. Tasks under initiating include selecting a project manager, forming the project team, and developing the project charter. Tasks under planning include 58

59 developing a scope statement, creating a WBS, and developing and refining other plans, which would be broken down in more detail for a real project. The tasks of concept, Web site design, Web site development, and roll out, which were WBS Level 2 items in Figure 3-3, now become WBS Level 3 items under executing. The executing tasks vary the most from project to project, but many of the tasks under the other project management process groups would be similar for all projects. If you do not use the project management process groups in the WBS, you can have a Level 2 category called project management to make sure that tasks related to managing the project are accounted for. Remember that all work should be included in the WBS, including project management. FIGURE 3-5 Intranet project Gantt chart organized by project management process groups Approaches to Developing Work Breakdown Structures There are several approaches you can use to develop a work breakdown structure. These approaches include: Using guidelines The analogy approach The top-down and bottom-up approaches The mind-mapping approach 59

60 Using guidelines: If guidelines for developing a WBS exist, it is very important to follow them. Some organizations, for example, the U.S. Department of Defence (DOD) prescribe the form and content for WBSs for particular projects. Many DOD projects require contractors to prepare their proposals based on the DOD-provided WBS. These proposals must include cost estimates for each task in the WBS at a detailed and summary level. The cost for the entire project must be calculated by summing the costs of all of the lower-level WBS tasks. When DOD personnel evaluate cost proposals, they must compare the contractors costs with the DOD s estimates. A large variation in costs for a certain WBS task often indicates confusion as to what work must be done. Many organizations provide guidelines and templates for developing WBSs, as well as examples of WBSs from past projects. Microsoft Project 2007 comes with several templates, and more are available on Microsoft s Web site and other sites. At the request of many of its members, the Project Management Institute developed a WBS Practice Standard to provide guidance for developing and applying the WBS to project management. This document includes sample WBSs for a wide variety of projects in various industries, including projects for Web design, telecom, service industry outsourcing, and software implementation. The Analogy Approach: Another approach for constructing a WBS is the analogy approach. In the analogy approach, you use a similar project s WBS as a starting point. Some organizations keep a repository of WBSs and other project documentation on file to assist people working on projects. Project 2007 and many other software tools include sample files to assist users in creating a WBS and Gantt chart. Viewing examples of other similar projects WBSs allows you to understand different ways to create a WBS. The Top-down and Bottom-up Approaches: Two other approaches for creating WBSs are the top-down and bottom-up approaches. Most project managers consider the top-down approach of WBS construction to be conventional. To use the top-down approach, start with the largest items of the project and break them into their subordinate items. This process involves refining the work into greater and greater levels of detail. For example, Figure 3-3 shows how work was broken down to Level 4 for part of the intranet project. After finishing the process, all resources 60

61 should be assigned at the work package level. The top-down approach is best suited to project managers who have vast technical insight and a big-picture perspective. In the bottom-up approach, team members first identify as many specific tasks related to the project as possible. They then aggregate the specific tasks and organize them into summary activities, or higher levels in the WBS. For example, a group of people might be responsible for creating a WBS to create an e-commerce application. Instead of looking for guidelines on how to create a WBS or viewing similar projects WBSs, they could begin by listing detailed tasks they think they would need to do in order to create the application. After listing these detailed tasks, they would group the tasks into categories. Then they would group these categories into higherlevel categories. Some people have found that writing all possible tasks down on notes and then placing them on a wall helps them see all the work required for the project and develop logical groupings for performing the work. For example, a business analyst on the project team might know that they had to define user requirements and content requirements for the e-commerce application. These tasks might be part of the requirements documents they would have to create as one of the project deliverables. A hardware specialist might know they had to define system requirements and server requirements, which would also be part of a requirements document. As a group, they might decide to put all four of these tasks under a higher-level item called define requirements that would result in the delivery of a requirements document. Later, they might realize that defining requirements should fall under a broader category of concept design for the e-commerce application, along with other groups of tasks related to the concept design. The bottom-up approach can be very time-consuming, but it can also be a very effective way to create a WBS. Project managers often use the bottom-up approach for projects that represent entirely new systems or approaches to doing a job, or to help create buy-in and synergy with a project team. Mind Mapping: Some project managers like to use mind mapping to help develop WBSs. Mind mapping is a technique that uses branches radiating out from a core idea to structure thoughts and ideas. Instead of writing tasks down in a list or immediately trying to create a structure for tasks, mind mapping allows people to write and even draw pictures of ideas in a nonlinear format. This more visual, less-structured approach to defining and then grouping tasks can unlock creativity among individuals and increase participation and morale among teams. 61

62 Figure 3-6 shows a diagram that uses mind mapping to create a WBS for the IT Upgrade Project. The figure was created using MindManager software by Mindjet ( The circle in the center represents the entire project. Each of the four main branches radiating out from the center represents the main tasks or Level 2 items for the WBS. Different people at the meeting creating this mind map might have different roles in the project, which could help in deciding the tasks and WBS structure. Branching off from the main task called Update inventory are two subtasks, Perform physical inventory and Update database. Branching off from the Perform physical inventory subtask are three further subdivisions, labelled Building A, Building B, and Building C, and so on. The team would continue to add branches and items until they have exhausted ideas on what work needs to be performed. FIGURE 3-7 Sample mind-mapping technique for creating a WBS The WBS Dictionary and Scope Baseline A WBS dictionary is a document that describes detailed information about each WBS item. The format of the WBS dictionary can vary based on project needs. It might be appropriate to have just a short paragraph describing each work package. For a more complex project, an entire page or more might be needed for the work package descriptions. Some projects might require that each WBS item describe the responsible organization, resource requirements, estimated costs, and other information. The approved project scope statement and its associated WBS and WBS dictionary form the scope baseline. Performance in meeting project scope goals is based on this scope baseline. 62

63 Advice for Creating a WBS and WBS Dictionary As stated previously, creating a good WBS is no easy task and usually requires several iterations. Often, it is best to use a combination of approaches to create a project s WBS. There are some basic principles, however, that apply to creating any good WBS and its WBS dictionary. A unit of work should appear at only one place in the WBS. The work content of a WBS item is the sum of the WBS items below it. A WBS item is the responsibility of only one individual, even though many people may be working on it. The WBS must be consistent with the way in which work is actually going to be performed; it should serve the project team first, and other purposes only if practical. Project team members should be involved in developing the WBS to ensure consistency and buy-in. Each WBS item must be documented in a WBS dictionary to ensure accurate understanding of the scope of work included and not included in that item. The WBS must be a flexible tool to accommodate inevitable changes while properly maintaining control of the work content in the project according to the scope statement. 3.6 VERIFYING SCOPE It is difficult to create a good project scope statement and WBS for a project. It is even more difficult, especially on information technology projects, to verify the project scope and minimize scope changes. Some project teams know from the start that the scope is very unclear and that they must work closely with the project customer to design and produce various deliverables. In this case, the project team must develop a process for scope verification that meets unique project needs. Careful procedures must be developed to ensure that the customer is getting what they want and the project team has enough time and money to produce the desired products and services. Even when the project scope is fairly well defined, many information technology projects suffer from scope creep-the tendency for project scope to keep getting bigger and bigger. For this reason, it is very important to verify the project scope with users throughout the life of the project and develop a process for controlling scope changes. 63

64 Scope verification involves formal acceptance of the completed project scope by the stakeholders. This acceptance is often achieved by a customer inspection and then sign-off on key deliverables. To receive formal acceptance of the project scope, the project team must develop clear documentation of the project s products and procedures to evaluate if they were completed correctly and satisfactorily. The project management plan, requirements documentation, the requirements traceability matrix, and validated deliverables are the main inputs for scope verification. The main tool for performing scope verification is inspection. The customer, sponsor, or user inspects the work after it is delivered. The main outputs of scope verification are accepted deliverables, change requests, and project document updates. 3.7 CONTROLLING SCOPE Change is inevitable on projects, especially changes to the scope of information technology projects. Scope control involves controlling changes to the project scope. Users often are not exactly sure how they want screens to look or what functionality they will really need to improve business performance. Developers are not exactly sure how to interpret user requirements, and they also have to deal with constantly changing technologies. The goal of scope control is to influence the factors that cause scope changes, assure changes are processed according to procedures developed as part of integrated change control, and manage changes when they occur. You cannot do a good job of controlling scope if you do not first do a good job of collecting requirements, defining scope, and verifying scope. How can you prevent scope creep when you have not agreed on the work to be performed and your sponsor has not verified that the proposed work was acceptable? You also need to develop a process for soliciting and monitoring changes to project scope. Stakeholders should be encouraged to suggest changes that will benefit the overall project and discouraged from suggesting unnecessary changes. The project management plan, work performance data, requirements documentation, requirements traceability matrix, and organizational process assets are the main inputs to scope control. An important tool for performing scope control is variance analysis. Variance is the difference between planned and actual performance. For example, if a supplier was supposed to 64

65 deliver five special keyboards and you received only four, the variance would be one keyboard. The outputs of scope control include work performance measurements, organizational process assets updates, change requests, project management plan updates, and project document updates. 3.8 SOFTWARE TO ASSIST IN PROJECT SCOPE MANAGEMENT Project managers and their teams can use several types of software to assist in project scope management. As shown in several of the figures and tables in this unit, you can use word processing software to create scope-related documents, and most people use spreadsheet or presentation software to develop various charts, graphs, and matrixes related to scope management. Mind-mapping software can be useful in developing a WBS. Project stakeholders also transmit project scope management information using various types of communication software such as and assorted Web-based applications. Project management software helps you develop a WBS, which serves as a basis for creating Gantt charts, assigning resources, allocating costs, and so on. You can also use the templates that come with various project management software products to help you create a WBS for your project. You can also use many types of specialized software to assist in project scope management. Many information technology projects use special software for requirements management, prototyping, modelling, and other scope-related work. Because scope is such a crucial part of project management, there are many software products available to assist in managing project scope. Project scope management is very important, especially on information technology projects. After selecting projects, organizations must collect the requirements and define the scope of the work, break down the work into manageable pieces, verify the scope with project stakeholders, and manage changes to project scope. Using the basic project management concepts, tools, and techniques discussed in this unit can help you successfully manage project scope. 65

66 3.9 SUMMARY Project scope management includes the processes required to ensure that the project addresses all the work required, and only the work required, to complete the project successfully. The main processes include collecting requirements, defining scope, creating the WBS, verifying scope, and controlling scope. The first step in project scope management is collecting requirements, a crucial part of many IT projects. It is important to review the project charter and meet with key stakeholders listed in the stakeholder register when collecting requirements. The main outputs of this process are requirements documentation, a requirements management plan, and a requirements traceability matrix. A project scope statement is created in the scope definition process. This document often includes a product scope description, product user acceptance criteria, detailed information on all project deliverables, and information on project boundaries, constraints, and assumptions. There are often several versions of the project scope statement to keep scope information detailed and up-to-date. A work breakdown structure (WBS) is a deliverable-oriented grouping of the work involved in a project that defines the total scope of the project. The WBS forms the basis for planning and managing project schedules, costs, resources, and changes. You cannot use project management software without first creating a good WBS. A WBS dictionary is a document that describes detailed information about each WBS item. A good WBS is often difficult to create because of the complexity of the project. There are several approaches for developing a WBS, including using guidelines, the analogy approach, the top-down approach, the bottom-up approach, and mind mapping. Verifying scope involves formal acceptance of the project scope by the stakeholders. Controlling scope involves controlling changes to the project scope. Poor project scope management is one of the key reasons projects fail. For information technology projects, it is important for good project scope management to have strong user involvement, a clear statement of requirements, and a process for managing scope changes. 66

67 There are many software products available to assist in project scope management. The WBS is a key concept in properly using project management software since it provides the basis for entering tasks KEYWORDS Project scope statement, analogy approach, bottom-up approach, top-down approach, mind mapping, scope base line, work breakdown structures, WBS dictionary QUESTIONS 1. What is involved in project scope management, and why is good project scope management so important on information technology projects? 2. What is involved in collecting requirements for a project? Why is it often such a difficult thing to do? 3. Discuss the process of defining project scope in more detail as a project progresses, going from information in a project charter to a project scope statement, WBS, and WBS dictionary. 4. Describe different ways to develop a WBS and explain why it is often so difficult to do. 5. What is the main technique used for verifying scope? Give an example of scope verification on a project. 6. Why do you need a good WBS to use project management software? What other types of software can you use to assist in project scope management? 3.12 EXERCISE 1. You are working on a project to develop a new or enhanced system to help people at your college, university, or organization to find jobs. The system must be tailored to your student or work population and be very easy to use. Write a two-page paper describing how you would collect requirements for this system and include at least five requirements in a requirements traceability matrix. 67

68 3.13 REFERENCE 7. Information Technology Project Management: Kathy Schwalbe, International Student Edition, Thomson Course Technology, Software Project Management: Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill. 9. Basics of Software Project Management: NIIT, Prentice-Hall of India, Software Project Management in Practice: Pankaj Jalote, Pearson Education, Software Project Management A Concise Study: S.A.Kelkar, Revised Edition, Prentice- Hall of India, Microsoft Office Project 2003 Bible: Elaine Marmel, Wiley Publishing Inc. 68

69 UNIT 4 PROJECT SCHEDULING STRUCTURE 4.0 Objectives 4.1 Introduction 4.2 The importance of Project Schedule 4.3 Defining Activities 4.4 Sequencing Activities 4.5 Estimating Activity Resources 4.6 Estimating Activity Durations 4.7 Developing the Schedule 4.8 Softwares to assist in Project Time Management 4.9 Summary 4.10 Keywords 4.11 Questions 4.12 Exercise 4.13 Reference 4.0 OBJECTIVES After studying this unit, you will be able to: Discuss the importance of project schedules and good project time management. Elucidate how project managers use network diagrams and dependencies to assist in activity sequencing. Evaluate the relationship between estimating resources and project schedules. Explain how various tools and techniques help project managers perform activity duration estimating. 69

70 Use a Gantt chart for planning and tracking schedule information, find the critical path for a project, and describe how critical chain scheduling and the Program Evaluation and Review Technique (PERT) affect schedule development. Discuss how reality checks and discipline are involved in controlling and managing changes to the project schedule. Describe how project management software can assist in project time management and review words of caution before using this software. 4.1 INTRODUCTION Many information technology projects are failures in terms of meeting scope, time, and cost projections. Managers often cite delivering projects on time as one of their biggest challenges and the main cause of conflict. Project-task scheduling is an important project planning activity. It involves deciding which tasks would be taken up when. The first step in scheduling a software project involves identifying all the tasks necessary to complete the project. A good knowledge of the intricacies of the project and the development process helps the managers to effectively identify the important tasks of the project. Next, the large tasks are broken down into a logical set of small activities which would be assigned to different engineers. The work breakdown structure formalism helps the manager to breakdown the tasks systematically. 4.2 THE IMPORTANCE OF PROJECT SCHEDULES Project time management, simply defined, involves the processes required to ensure timely completion of a project. Achieving timely completion of a project, however, is by no means simple. There are six main processes involved in project time management: Defining activities involves identifying the specific activities that the project team members and stakeholders must perform to produce the project deliverables. An activity or task is an element of work normally found on the work breakdown structure (WBS) that has an expected duration, a cost, and resource requirements. The main outputs of this process are an activity list, activity attributes, and milestone list. 70

71 Sequencing activities involves identifying and documenting the relationships between project activities. The main outputs of this process include project schedule network diagrams and project document updates. Estimating activity resources involves estimating how many resources people, equipment, and materials a project team should use to perform project activities. The main outputs of this process are activity resource requirements, a resource breakdown structure, and project document updates. Estimating activity durations involve estimating the number of work periods that are needed to complete individual activities. Outputs include activity duration estimates and project document updates. Developing the schedule involves analyzing activity sequences, activity resource estimates, and activity duration estimates to create the project schedule. Outputs include a project schedule, a schedule baseline, schedule data, and project document updates. Controlling the schedule involves controlling and managing changes to the project schedule. Outputs include work performance measurements, organizational process assets updates, change requests, project management plan updates, and project document updates. Figure 4-1 summarizes these processes and outputs and shows when they occur in a typical project. 71

72 4.3 DEFINING ACTIVITIES FIGURE 4-1 Project time management summary Project schedules grow out of the basic documents that initiate a project. The project charter often mentions planned project start and end dates, which serve as the starting points for a more detailed schedule. The project manager starts with the project charter and develops a project scope statement and WBS. The project charter should also include some estimate of how much money will be allocated to the project. Using this information with the main inputs for defining activities - the scope baseline (the scope statement, WBS, and WBS dictionary), enterprise environmental factors, and organizational process assets - the project manager and project team begin developing a detailed list of activities, their attributes, and a milestone list. The activity list is a tabulation of activities to be included on a project schedule. The list should include the activity name, an activity identifier or number, and a brief description of the activity. The activity attributes provide more schedule-related information about each activity, such as predecessors, successors, logical relationships, leads and lags, resource requirements, constraints, imposed dates, and assumptions related to the activity. The activity list and activity attributes should be in agreement with the WBS and WBS dictionary. Information is added to the activity attributes as it becomes available, such as logical relationships and resource requirements that are determined in later processes. Many project teams use an automated system to keep track of all of this activity-related information. A milestone on a project is a significant event that normally has no duration. It often takes several activities and a lot of work to complete a milestone, but the milestone itself is like a marker to help in identifying necessary activities. Milestones are also useful tools for setting schedule goals and monitoring progress. For example, milestones on a project like the one in the opening case might include completion and customer sign-off of documents, such as design documents and test plans; completion of specific products, such as software modules or installation of new hardware; and completion of important process-related work, such as project review meetings, tests, and so on. Not every deliverable or output created for a project is really a milestone. Milestones are the most important and visible ones. For example, the term milestone 72

73 is used in several contexts, such as in child development. Parents and doctors check for milestones, such as a child first rolling over, sitting, crawling, walking, talking, and so on. Activity information is a required input to the other time management processes. You cannot determine activity sequencing, resources, or durations, develop the schedule, or control the schedule until you have a good understanding of project activities. The goal of the defining activities is to ensure that the project team has complete understanding of all the work they must do as part of the project scope so they can start scheduling the work. For example, a WBS item might be Produce study report. The project team would have to understand what that means before they can make schedule-related decisions. How long should the report be? Does it require a survey or extensive research to produce it? What skill level does the report writer need to have? Further defining that task will help the project team determine how long it will take to do and who should do it. The WBS is often dissected further as the project team members further define the activities required for performing the work. For example, the task Produce study report might be broken down into several subtasks describing the steps involved in producing the report, such as developing a survey, administering the survey, analyzing the survey results, performing research, writing a draft report, editing the report, and finally producing the report. As stated earlier, activities or tasks are elements of work performed during the course of a project; they have expected durations, costs, and resource requirements. Defining activities also results in supporting detail to document important product information as well as assumptions and constraints related to specific activities. The project team should review the activity list and activity attributes with project stakeholders before moving on to the next step in project time management. If they do not review these items, they could produce an unrealistic schedule and deliver unacceptable results. For example, if a project manager simply estimated that it would take one day for the Produce study report task and had an intern or trainee write a 10-page report to complete that task, the result could be a furious customer who expected extensive research, surveys, and a 100-page report. Clearly defining the work is crucial to all projects. If there are misunderstandings about activities, requested changes may be required. 73

74 4.4 SEQUENCING ACTIVITIES After defining project activities, the next step in project time management is sequencing them or determining their dependencies. Inputs to the activity sequencing process include the activity list and attributes, project scope statement, milestone list, and organizational process assets. It involves evaluating the reasons for dependencies and the different types of dependencies. Dependencies A dependency or relationship relates to the sequencing of project activities or tasks. For example, does a certain activity have to be finished before another one can start? Can the project team do several activities in parallel? Can some overlap? Determining these relationships or dependencies between activities has a significant impact on developing and managing a project schedule. There are three basic reasons for creating dependencies among project activities: Mandatory dependencies are inherent in the nature of the work being performed on a project. They are sometimes referred to as hard logic. For example, you cannot test code until after the code is written. Discretionary dependencies are defined by the project team. For example, a project team might follow good practice and not start the detailed design of a new information system until the users sign off on all of the analysis work. Discretionary dependencies are sometimes referred to as soft logic and should be used with care since they may limit later scheduling options. External dependencies involve relationships between project and non-project activities. The installation of a new operating system and other software may depend on delivery of new hardware from an external supplier. Even though the delivery of the new hardware may not be in the scope of the project, you should add an external dependency to it because late delivery will affect the project schedule. As with activity definition, it is important that project stakeholders work together to define the activity dependencies that exist on their project. If you do not define the sequence of activities, you cannot use some of the most powerful schedule tools available to project managers: network diagrams and critical path analysis. 74

75 Network Diagrams Network diagrams are the preferred technique for showing activity sequencing. A network diagram is a schematic display of the logical relationships among, or sequencing of, project activities. Some people refer to network diagrams as project schedule network diagrams or PERT charts. PERT is described later in this chapter. Figure 4-2 shows a sample network diagram for Project X, which uses the arrow diagramming method (ADM) or activity-on arrow (AOA) approach. Note: Assume all durations are in days; A=1 means Activity A has a duration of 1 day. FIGURE 4-2 Activity-on-arrow (AOA) network diagram for Project X Note the main elements on this network diagram. The letters A through J represent activities with dependencies that are required to complete the project. These activities come from the WBS and activity definition process described earlier. The arrows represent the activity sequencing or relationships between tasks. For example, Activity A must be done before Activity D; Activity D must be done before Activity H, and so on. The format of this network diagram uses the activity-on-arrow (AOA) approach or the arrow diagramming method (ADM) a network diagramming technique in which activities are represented by arrows and connected at points called nodes to illustrate the sequence of activities. A node is simply the starting and ending point of an activity. The first node signifies the start of a project, and the last node represents the end of a project. Keep in mind that the network diagram represents activities that must be done to complete the project. It is not a race to get from the first node to the last node. Every activity on the network diagram must be completed in order for the project to finish. It is also important to note that not 75

76 every single item on the WBS needs to be on the network diagram; only activities with dependencies need to be shown on the network diagram. However, some people like to have start and end milestones and to list every activity. It is a matter of preference. For projects with hundreds of activities, it might be simpler to include only activities with dependencies on a network diagram, especially on large projects. Sometimes it is enough to put summary tasks on a network diagram or to break down the project into several smaller network diagrams. Assuming you have a list of the project activities and their start and finish nodes, follow these steps to create an AOA network diagram: 1. Find all of the activities that start at Node 1. Draw their finish nodes, and draw arrows between Node 1 and each of those finish nodes. Put the activity letter or name on the associated arrow. If you have a duration estimate, write that next to the activity letter or name, as shown in Figure 4-2. For example, A = 1 means that the duration of Activity A is one day, week, or other standard unit of time. Also be sure to put arrowheads on all arrows to signify the direction of the relationships. 2. Continue drawing the network diagram, working from left to right. Look for bursts and merges. Bursts occur when two or more activities follow a single node. A merge occurs when two or more nodes precede a single node. For example, in Figure 4-2, Node 1 is a burst since it goes into Nodes 2, 3, and 4. Node 5 is a merge preceded by Nodes 2 and Continue drawing the AOA network diagram until all activities are included on the diagram. 4. As a rule of thumb, all arrowheads should face toward the right, and no arrows should cross on an AOA network diagram. You may need to redraw the diagram to make it look presentable. Even though AOA or ADM network diagrams are generally easy to understand and create, a different method is more commonly used: the precedence diagramming method. The precedence diagramming method (PDM) is a network diagramming technique in which boxes represent activities. It is particularly useful for visualizing certain types of time relationships. 76

77 4.5 ESTIMATING ACTIVITY RESOURCES Before you can estimate the duration for each activity, you must have a good idea of the quantity and type of resources (people, equipment, and materials) that will be assigned to each activity. The nature of the project and the organization will affect resource estimating. Expert judgment, an analysis of alternatives, estimating data, and project management software are tools available to assist in resource estimating. It is important that the people who help determine what resources are necessary include people who have experience and expertise in similar projects and with the organization performing the project. Important questions to answer in activity resource estimating include: How difficult will it be to do specific activities on this project? Is there anything unique in the project s scope statement that will affect resources? What is the organization s history in doing similar activities? Has the organization done similar tasks before? What level of personnel did the work? Does the organization have people, equipment, and materials that are capable and available for performing the work? Are there any organizational policies that might affect the availability of resources? Does the organization need to acquire more resources to accomplish the work? Would it make sense to outsource some of the work? Will outsourcing increase or decrease the amount of resources needed and when they will be available? A project s activity list, activity attributes, resource calendars or availability, enterprise environmental factors, and organizational process assets (such as policies regarding staffing and outsourcing) are all important inputs to answering these questions. During the early phases of a project, the project team may not know which specific people, equipment, and materials will be available. For example, they might know from past projects that there will be a mix of experienced and inexperienced programmers working on a project. They might also have information available that approximates the number of people or hours it normally takes to perform specific activities. 77

78 It is important to thoroughly brainstorm and evaluate alternatives related to resources, especially on projects that involve people from multiple disciplines and companies. Since most projects involve many human resources and the majority of costs are for salaries and benefits, it is often effective to solicit ideas from different people to help develop alternatives and address resourcerelated issues early in a project. The resource estimates should also be updated as more detailed information becomes available. The main outputs of the resource estimating process include a list of activity resource requirements, a resource breakdown structure, and project document updates. For example, if junior employees will be assigned to many activities, the project manager might request that additional activities, time, and resources be approved to help train and mentor those employees. In addition to providing the basis for estimating activity durations, estimating activity resources provides vital information for project cost estimating, project human resource management, project communications management, project risk management, and project procurement management. 4.6 ESTIMATNG ACTIVITY DURATIONS After working with key stakeholders to define activities, determine their dependencies, and estimate their resources, the next process in project time management is to estimate the duration of activities. It is important to note that duration includes the actual amount of time worked on an activity plus elapsed time. For example, even though it might take one workweek or five workdays to do the actual work, the duration estimate might be two weeks to allow extra time needed to obtain outside information. The resources assigned to a task will also affect the task duration estimate. Do not confuse duration with effort, which is the number of workdays or work hours required to complete a task. A duration estimate of one day could be based on eight hours of work or eighty hours of work. Duration relates to the time estimate, not the effort estimate. Of course, the two are related, so project team members must document their assumptions when creating duration estimates and update the estimates as the project progresses. The people who will actually do the work, in particular, should have a lot of say in these duration estimates, since they are the ones 78

79 whose performance will be evaluated on meeting them. If scope changes occur on the project, the duration estimates should be advice of experts in estimating activity durations. There are several inputs to activity duration estimating. The activity list, activity attributes, activity resource requirements, resource calendars, project scope statement, enterprise environmental factors, and organizational process assets all include information that affect duration estimates. In addition to reviewing past project information, the team should also review the accuracy of the duration estimates thus far on the project. For example, if they find that all of their estimates have been much too long or short; the team should update the estimates to reflect what they have learned. One of the most important considerations in making activity duration estimates is the availability of resources, especially human resources. What specific skills do people need to do the work? What are the skill levels of the people assigned to the project? How many people are expected to be available to work on the project at any one time? The outputs of activity duration estimating include activity duration estimates and project document updates. Duration estimates are often provided as a discrete number, such as four weeks, or as a range, such as three to five weeks, or as a three-point estimate. A three-point estimate is an estimate that includes an optimistic, most likely, and pessimistic estimate, such as three weeks for the optimistic, four weeks for the most likely, and five weeks for the pessimistic estimate. The optimistic estimate is based on a best-case scenario, while the pessimistic estimate is based on a worst-case scenario. The most likely estimate, as it sounds, is an estimate based on a most likely or expected scenario. 4.7 DEVELOPING THE SCHEDULE Schedule development uses the results of all the preceding project time management processes to determine the start and end dates of the project. There are often several iterations of all the project time management processes before a project schedule is finalized. The ultimate goal of developing the schedule is to create a realistic project schedule that provides a basis for monitoring project progress for the time dimension of the project. The main outputs of this process are the project schedule, a schedule baseline, project document updates, and schedule data. Some project teams create a computerized model to create a network diagram, enter 79

80 resource requirements and availability by time period, and adjust other information to quickly generate alternative schedules. Several tools and techniques assist in schedule development: A Gantt chart is a common tool for displaying project schedule information. Critical path analysis is a very important tool for developing and controlling project schedules. Critical chain scheduling is a technique that focuses on limited resources when creating a project schedule. PERT analysis is a means for considering schedule risk on projects. Gantt Charts Gantt charts provide a standard format for displaying project schedule information by listing project activities and their corresponding start and finish dates in a calendar format. Gantt charts are sometimes referred to as bar charts since the activities start and end dates are shown as horizontal bars. Figure 4-3 shows a simple Gantt chart for Project X created with Microsoft Project. Figure 4-4 shows a Gantt chart that is more sophisticated based on a software launch project from a template provided by Microsoft. Recall that the activities on the Gantt chart should coincide with the activities on the WBS, which should coincide with the activity list and milestone list. Notice that the software launch project s Gantt chart contains milestones, summary tasks, individual task durations, and arrows showing task dependencies. 80

81 FIGURE 4-3 Gantt chart for Project X Notice the different symbols on the software launch project s Gantt chart (Figure 4-4): The black diamond symbol represents a milestone. In Figure 4-4, Task 1, Marketing Plan distributed, is a milestone that occurs on March 17. Tasks 3, 4, 8, 9, 14, 25, 27, 43, and 45 are also milestones. For very large projects, top managers might want to see only milestones on a Gantt chart. Microsoft Project allows you to filter information displayed on a Gantt chart so you can easily show specific tasks, such as milestones. The thick black bars with arrows at the beginning and end represent summary tasks. For example, Activities 12 through 15 Develop creative briefs, Develop concepts, Creative concepts, and Ad development are all subtasks of the summary task called Advertising, Task 11. WBS activities are referred to as tasks and subtasks in most project management software. The light gray horizontal bars such as those found in Figure 4-4 for Tasks 5, 6, 7, 10, 12, 13, 15, 22, 24, 26, and 44, represent the duration of each individual task. For example, the light gray bar for Subtask 5, Packaging, starts in mid-february and extends until early May. Arrows connecting these symbols show relationships or dependencies between tasks. Gantt charts often do not show dependencies, which is their major disadvantage. If dependencies have been established in Microsoft Project, they are automatically displayed on the Gantt chart. 81

82 FIGURE 4-4 Gantt chart for software launch project Critical Path Method Many projects fail to meet schedule expectations. Critical path method (CPM) also called critical path analysis is a network diagramming technique used to predict total project duration. This important tool will help you combat project schedule overruns. A critical path for a project is the series of activities that determine the earliest time by which the project can be completed. It is the longest path through the network diagram and has the least amount of slack or float. Slack or float is the amount of time an activity may be delayed without delaying a succeeding activity or the project finish date. There are normally several tasks done in parallel on projects, and most projects have multiple paths through a network diagram. The longest path or path 82

83 containing the critical tasks is what is driving the completion date for the project. You are not finished with the project until you have finished all the tasks. Calculating the Critical Path To find the critical path for a project, you must first develop a good network diagram, which, in turn, requires a good activity list based on the WBS. Once you create a network diagram, you must also estimate the duration of each activity to determine the critical path. Calculating the critical path involves adding the durations for all activities on each path through the network diagram. The longest path is the critical path. Figure 4-5 shows the AOA network diagram for Project X again. Note that you can use either the AOA or precedence diagramming method to determine the critical path on projects. Figure 4-5 shows all of the paths a total of four through the network diagram. Note that each path starts at the first node (1) and ends at the last node (8) on the AOA network diagram. This figure also shows the length or total duration of each path through the network diagram. These lengths are computed by adding the durations of each activity on the path. Since path B-E-H-J at 16 days has the longest duration, it is the critical path for the project. FIGURE 4-5 Determining the critical path for Project X Note: Assume all durations are in days Path 1: A-D-H-J Length = = 14 days Path 2: B-E-H-J Length = = 16 days Path 3: B-F-J Length = = 9 days 83

84 Path 4: C-G-I-J Length = = 14 days Since the critical path is the longest path through the network diagram, Path 2, B-E-H-J, is the critical path for Project X. What does the critical path really mean? The critical path shows the shortest time in which a project can be completed. Even though the critical path is the longest path, it represents the shortest time it takes to complete a project. If one or more of the activities on the critical path takes longer than planned, the whole project schedule will slip unless the project manager takes corrective action. Program Evaluation and Review Technique (PERT) Another project time management technique is the Program Evaluation and Review Technique (PERT) a network analysis technique used to estimate project duration when there is a high degree of uncertainty about the individual activity duration estimates. PERT applies the critical path method (CPM) to a weighted average duration estimate. This approach was developed about the same time as CPM, in the late 1950s, and also uses network diagrams, which are still sometimes referred to as PERT charts. PERT uses probabilistic time estimates duration estimates based on using optimistic, most likely, and pessimistic estimates of activity durations instead of one specific or discrete duration estimate, as CPM does. In other words, PERT uses a three-point estimate, as described earlier. To use PERT, you calculate a weighted average for the duration estimate of each project activity using the following formula: By using the PERT weighted average for each activity duration estimate, the total project duration estimate takes into account the risk or uncertainty in the individual activity estimates. Suppose a project team used PERT to determine the schedule for the online registration system project. They would have to collect numbers for the optimistic, most likely, and pessimistic duration estimates for each project activity. Suppose one of the activities was to design an input screen for the system. Someone might estimate that it would take about two weeks or 10 workdays to do this activity. Without using PERT, the duration estimate for that activity would 84

85 be 10 workdays. Using PERT, the project team would also need to estimate the pessimistic and optimistic times for completing this activity. Suppose an optimistic estimate is that the input screen can be designed in eight workdays, and a pessimistic time estimate is 24 workdays. Applying the PERT formula, you get the following: Instead of using the most likely duration estimate of 10 workdays, the project team would use 12 workdays when doing critical path analysis. These additional two days could really help the project team in getting the work completed on time. The main advantage of PERT is that it attempts to address the risk associated with duration estimates. Since many projects exceed schedule estimates, PERT may help in developing schedules that are more realistic. PERT s main disadvantages are that it involves more work than CPM since it requires several duration estimates, and there are better probabilistic methods for assessing schedule risk. 4.8 SOFTWARE TO ASSIST IN PROJECT TIME MANAGEMENT Several types of software are available to assist in project time management. Software for facilitating communications helps project managers exchange schedule-related information with project stakeholders. Decision support models can help project managers analyze various tradeoffs that can be made related to schedule issues. However, project management software, such as Microsoft Project 2007, was designed specifically for performing project management tasks. You can use project management software to draw network diagrams, determine the critical path for a project, create Gantt charts, and report, view, and filter specific project time management information. Many projects involve hundreds of tasks with complicated dependencies. After you enter the necessary information, project management software automatically generates a network diagram and calculates the critical path(s) for the project. It also highlights the critical path in red on the network diagram. Project management software also calculates the free and total float or slack 85

86 for all activities. Using project management software eliminates the need to perform cumbersome calculations manually and allows for what if analysis as activity duration estimates or dependencies change. Recall that knowing which activities have the most slack gives the project manager an opportunity to reallocate resources or make other changes to compress the schedule or help keep it on track. Project 2007 easily creates Gantt charts and Tracking Gantt charts, which make tracking actual schedule performance versus the planned or baseline schedule much easier. It is important, however, to enter actual schedule information in a timely manner in order to benefit from using the Tracking Gantt chart feature. Some organizations use or other communications software to send up-to-date task and schedule information to the person responsible for updating the schedule. He or she can then quickly authorize these updates and enter them directly into the project management software. This process provides an accurate and up-to-date project schedule in Gantt chart form. Project 2007 also includes many built-in reports, views, and filters to assist in project time management. For example, a project manager can quickly run a report to list all tasks that are to start soon. He or she could then send out a reminder to the people responsible for these tasks. If the project manager were presenting project schedule information to top management, he or she could create a Gantt chart showing only summary tasks or milestones. You can also create custom reports, views, tables, and filters. 4.9 SUMMARY Project time management is often cited as the main source of conflict on projects. Most information technology projects exceed time estimates. The main processes involved in project time management include defining activities, sequencing activities, estimating activity resources, estimating activity durations, developing the schedule, and controlling the schedule. Defining activities involves identifying the specific activities that must be done to produce the project deliverables. It usually results in a more detailed WBS. Sequencing activities determines the relationships or dependencies between activities. Three reasons for creating relationships are that they are mandatory based on the nature of the work, discretionary based on the project team's experience, or external based on non-project activities. Activity sequencing must be done 86

87 in order to use critical path analysis. Network diagrams are the preferred technique for showing activity sequencing. The two methods used for creating these diagrams are the arrow diagramming method and the precedence diagramming method. Estimating activity resources involves determining the quantity and type of resources (people, equipment, and materials) that will be assigned to each activity. The nature of the project and the organization will affect resource estimating. Estimating activity durations creates estimates for the amount of time it will take to complete each activity. These time estimates include the actual amount of time worked plus elapsed time. Developing the schedule uses results from all of the other project time management processes to determine the start and end dates for the project. Project managers often use Gantt charts to display the project schedule. Tracking Gantt charts show planned and actual schedule information. The critical path method predicts total project duration. The critical path for a project is the series of activities that determines the earliest completion date for the project. It is the longest path through a network diagram. If any activity on the critical path slips, the whole project will slip unless the project manager takes corrective action. Crashing and fast tracking are two techniques for shortening project schedules. Project managers and their team members must be careful about accepting unreasonable schedules, especially for information technology projects. The Program Evaluation and Review Technique (PERT) is a network analysis technique used to estimate project duration when there is a high degree of uncertainty about the individual activity duration estimates. It uses optimistic, most likely, and pessimistic estimates of activity durations. PERT is seldom used today. Project management software can assist in project scheduling if used properly. With project management software, you can avoid the need to perform cumbersome calculations manually and perform what if analysis as activity duration estimates or dependencies change. Many people misuse project management software because they do not understand the concepts behind creating a network diagram, determining the critical path, or setting a schedule baseline. Project managers must also avoid over-relying on sample files or templates when creating their unique project schedules. 87

88 4.10 KEYWORDS Activity, Activity-on-Arrow, Arrow diagramming method, Critical path, Gantt chart, Milestone, Network diagram, PERT technique, Resources, Slack, Task QUESTIONS 1. Why do you think schedule issues often cause the most conflicts on projects? 2. Why is defining activities the first process involved in project time management? 3. Why is it important to determine activity sequencing on projects? 4. Discuss diagrams you have seen that are similar to network diagrams. Describe their similarities and differences. 5. How does activity resource estimating affect estimating activity durations? 6. Explain the difference between estimating activity durations and estimating the effort required to perform an activity. 7. Explain the following schedule development tools and concepts: Gantt charts, critical path method, and PERT. 8. List some of the reports you can generate with Project 2007 to assist in project time management EXERCISE 1. Consider the following Network Diagram Data for a Small Project. All duration estimates or estimated times are in days; and the network proceeds from Node 1 to Node 9. a. Draw an AOA network diagram representing the project. Put the node numbers in circles and draw arrows from node to node, labelling each arrow with the activity letter and estimated time. b. Identify all of the paths on the network diagram and note how long they are, using Figure 4-5 as a guide for how to represent each path. c. What is the critical path for this project and how long is it? 88

89 d. What is the shortest possible time it will take to complete this project? Network diagram data for a small project 4.13 REFERENCE 13. Information Technology Project Management: Kathy Schwalbe, International Student Edition, Thomson Course Technology, Software Project Management: Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill. 15. Basics of Software Project Management: NIIT, Prentice-Hall of India, Software Project Management in Practice: Pankaj Jalote, Pearson Education, Software Project Management A Concise Study: S.A.Kelkar, Revised Edition, Prentice- Hall of India, Microsoft Office Project 2003 Bible: Elaine Marmel, Wiley Publishing Inc. 89

90 UNIT 5 PROJECT COST ESTIMATION STRUCTURE 5.0 Objectives 5.1 Introduction 5.2 Project Cost Management 5.3 Basic Principles of Cost Management 5.4 Estimating Costs 5.5 Summary 5.6 Keywords 5.7 Questions 5.8 Exercise 5.9 Reference 5.0 OBJECTIVES After studying this unit, you will be able to: Explain the importance of project cost management. Explain basic project cost management principles, concepts, and terms. Discuss different types of cost estimates and methods for preparing them. 5.1 INTRODUCTION A popular cost accounting textbook states, Accountants usually define cost as a resource sacrificed or foregone to achieve a specific objective. Webster s dictionary defines cost as something given up in exchange. Costs are often measured in monetary amounts, such as Rupees that must be paid to acquire goods and services. Because projects cost money and 90

91 consume resources that could be used elsewhere, it is very important for project managers to understand project cost management. Many information technology professionals, however, often react to cost overrun information with a smirk. They know that many of the original cost estimates for information technology projects are low to begin with or based on very unclear project requirements, cost estimates from the outset is only one part of the problem. In addition, many information technology professionals think preparing cost estimates is a job for accountants. On the contrary, preparing good cost estimates is a very demanding, important skill that many professionals need to acquire. Another perceived reason for cost overruns is that many information technology projects involve new technology or business processes. Any new technology or business process is untested and has inherent risks. Thus, costs grow and failures are to be expected. A good project cost management can minimize the budgetary risks and leads to project success. 5.2 PROJECT COST MANAGEMENT Project cost management includes the processes required to ensure that a project team completes a project within an approved budget. Notice two crucial phrases in this definition: a project and approved budget. Project managers must make sure their projects are well defined, have accurate time and cost estimates, and have a realistic budget that they were involved in approving. It is the project manager s job to satisfy project stakeholders while continuously striving to reduce and control costs. There are three project cost management processes: 1. Estimating costs involves developing an approximation or estimate of the costs of the resources needed to complete a project. The main outputs of the cost estimating process are activity cost estimates, basis of estimates, and project document updates. A cost management plan is created as part of integration management when creating the project management plan. It should include information related to the level of accuracy for estimates, variance thresholds for monitoring cost performance, reporting formats, and other related information. 2. Determining the budget involves allocating the overall cost estimate to individual work items to establish a baseline for measuring performance. The main outputs of the cost 91

92 budgeting process are a cost performance baseline, project funding requirements, and project document updates. 3. Controlling costs involves controlling changes to the project budget. The main outputs of the cost control process are work performance measurements, budget forecasts, organizational process asset updates, change requests, project management plan updates, and project document updates. Figure 1-1 summarizes these processes and outputs and shows when they occur in a typical project. FIGURE 1-1 Project cost management summary To understand each of the project cost management processes, you must first understand the basic principles of cost management. Many of these principles are not unique to project management; however, project managers need to understand how these principles relate to their specific projects. 5.3 BASIC PRINCIPLES OF COST MANAGEMENT Many information technology projects are never initiated because information technology professionals do not understand the importance of basic accounting and finance principles. Many projects that are started never finish because of cost management problems. Most members of an executive board have a better understanding of and are more interested in financial terms than 92

93 information technology terms. Therefore, information technology project managers need to be able to present and discuss project information in financial terms as well as in technical terms. In addition to net present value analysis, return on investment, and payback analysis, project managers must understand several other cost management principles, concepts, and terms. This section describes general topics such as profits, life cycle costing, cash flow analysis, tangible and intangible costs and benefits, direct costs, sunk costs, learning curve theory, and reserves. Profits are revenues minus expenditures. To increase profits, a company can increase revenues, decrease expenses, or try to do both. Most executives are more concerned with profits than with other issues. When justifying investments in new information systems and technology, it is important to focus on the impact on profits, not just revenues or expenses. Consider an e- commerce application that you estimate will increase revenues for a Rs. 100 crore company by 10 percent. You cannot measure the potential benefits of the e-commerce application without knowing the profit margin. Profit margin is the ratio of revenues to profits. If revenues of Rs. 100 generate Rs. 2 in profits, there is a 2 percent profit margin. If the company loses Rs. 2 for every Rs. 100 in revenue, there is a 2 percent profit margin. Life cycle costing allows you to see a big-picture view of the cost of a project throughout its life cycle. This helps you develop an accurate projection of a project s financial costs and benefits. Life cycle costing considers the total cost of ownership, or development plus support costs, for a project. For example, a company might complete a project to develop and implement a new customer service system in one or two years, but the new system could be in place for ten years. Project managers, with assistance from financial experts in their organizations, should create estimates of the costs and benefits of the project for its entire life cycle, or ten years in the preceding example. Recall that the net present value analysis for the project would include the entire ten-year period of costs and benefits. Top management and project managers need to consider the life cycle costs of projects when they make financial decisions. Organizations have a history of not spending enough money in the early phases of information technology projects, which impacts total cost of ownership. For example, it is much more costeffective to spend money on defining user requirements and doing early testing on information technology projects than to wait for problems to appear after implementation. 93

94 It is understood that it can cost over 100 times more to correct a defect on a software project that is found late in the project than to fix it early. Since organizations depend on reliable information technology, there are also huge costs associated with downtime. For example, Table 1-1 summarizes the average cost of a minute of downtime for different IT applications. Costs include the cost to bring the system back up, staff cost to make up for the lost work in production during the system downtime, and direct and indirect lost revenue. TABLE 1-1 Costs of downtime for IT applications Cash flow analysis is a method for determining the estimated annual costs and benefits for a project and the resulting annual cash flow. Project managers must conduct cash flow analysis to determine net present value. Most consumers understand the basic concept of cash flow. If they do not have enough money in their wallets or checking/credit accounts, they cannot purchase something. Top management must consider cash flow concerns when selecting projects in which to invest. If top management selects too many projects that have high cash flow needs in the same year, the company will not be able to support all of its projects and maintain its profitability. It is also important to define clearly the year on which the company bases the dollar amounts. For example, if a company bases all costs on 2008 estimates, it would need to account for inflation and other factors when projecting costs and benefits in future-year dollars. Tangible and intangible costs and benefits are categories for determining how definable the estimated costs and benefits are for a project. Tangible costs or benefits are those costs or benefits that an organization can easily measure in dollars. Conversely, intangible costs or 94

95 benefits are costs or benefits that are difficult to measure in monetary terms. Intangible benefits for projects often include items like goodwill, prestige, and general statements of improved productivity that an organization cannot easily translate into dollar amounts. Because intangible costs and benefits are difficult to quantify, they are often harder to justify. Direct costs are costs that can be directly related to producing the products and services of the project. You can attribute direct costs directly to a certain project. For example, the salaries of people working full time on the project and the cost of hardware and software purchased specifically for the project are direct costs. Project managers should focus on direct costs, since they can control them. Indirect costs are costs that are not directly related to the products or services of the project, but are indirectly related to performing the project. For example, the cost of electricity, paper towels, and so on in a large building housing a thousand employees who work on many projects would be indirect costs. Indirect costs are allocated to projects, and project managers have very little control over them. Sunk cost is money that has been spent in the past. Consider it gone, like a sunken ship that can never be returned. When deciding what projects to invest in or continue, you should not include sunk costs. Many people fall into the trap of considering how much money has been spent on a failing project and, therefore, hate to stop spending money on it. This trap is similar to gamblers not wanting to stop gambling because they have already lost money. Sunk costs should be forgotten. Learning curve theory states that when many items are produced repetitively, the unit cost of those items decreases in a regular pattern as more units are produced. For example, if a company produce 1,000 handheld devices that could run the new software and access information via satellite. The cost of the first handheld device or unit would be much higher than the cost of the thousandth unit. Learning curve theory should help estimate costs on projects involving the production of large quantities of items. Learning curve theory also applies to the amount of time it takes to complete some tasks. For example, the first time a new employee performs a specific task, it will probably take longer than the tenth time that employee performs a very similar task. Reserves are dollars included in a cost estimate to mitigate cost risk by allowing for future situations that are difficult to predict. Contingency reserves allow for future situations that may 95

96 be partially planned for (sometimes called known unknowns) and are included in the project cost baseline. For example, if an organization knows it has a 20 percent rate of turnover for information technology personnel, it should include contingency reserves to pay for recruiting and training costs for information technology personnel. Management reserves allow for future situations that are unpredictable (sometimes called unknown unknowns). For example, if a project manager gets sick for two weeks or an important supplier goes out of business, management reserve could be set aside to cover the resulting costs. 5.4 ESTIMATING COSTS Project managers must take cost estimates seriously if they want to complete projects within budget constraints. After developing a good resource requirements list, project managers and their project teams must develop several estimates of the costs for these resources. Recall that an important process in project time management is estimating activity resources, which provides a list of activity resource requirements. For example, if an activity on a project is to perform a particular type of test, the list of activity resource requirements would describe the skill level of the people needed to perform the test, the number of people and hours suggested to perform the test, the need for special software or equipment, and so on. All of this information is required to develop a good cost estimate. This section describes various types of cost estimates, tools and techniques for estimating costs, typical problems associated with information technology cost estimates, and a detailed example of a cost estimate for an information technology project. Types of Cost Estimates One of the main outputs of project cost management is a cost estimate. Project managers normally prepare several types of cost estimates for most projects. Three basic types of estimates include the following: A rough order of magnitude (ROM) estimate provides an estimate of what a project will cost. ROM estimates can also be referred to as a ballpark estimate, a guesstimate, a swag, or a broad gauge. This type of estimate is done very early in a project or even before a project is officially started. Project managers and top management use this estimate to help make project selection 96

97 decisions. The timeframe for this type of estimate is often three or more years prior to project completion. A ROM estimate s accuracy is typically -50 percent to +100 percent, meaning the project s actual costs could be 50 percent below the ROM estimate or 100 percent above. For example, the actual cost for a project with a ROM estimate of $100,000 could range between $50,000 and $200,000. For information technology project estimates, this accuracy range is often much wider. Many information technology professionals automatically double estimates for software development because of the history of cost overruns on information technology projects. A budgetary estimate is used to allocate money into an organization s budget. Many organizations develop budgets at least two years into the future. Budgetary estimates are made one to two years prior to project completion. The accuracy of budgetary estimates is typically 10 percent to 25 percent, meaning the actual costs could be -10 percent less or +25 percent more than the budgetary estimate. For example, the actual cost for a project with a budgetary estimate of $100,000 could range between $90,000 and $125,000. A definitive estimate provides an accurate estimate of project costs. Definitive estimates are used for making many purchasing decisions for which accurate estimates are required and for estimating final project costs. For example, if a project involves purchasing 1,000 personal computers from an outside supplier in the next three months, a definitive estimate would be required to aid in evaluating supplier proposals and allocating the funds to pay the chosen supplier. Definitive estimates are made one year or less prior to project completion. A definitive estimate should be the most accurate of the three types of estimates. The accuracy of this type of estimate is normally -5 percent to +10 percent, meaning the actual costs could be 5 percent less or 10 percent more than the definitive estimate. For example, the actual cost for a project with a definitive estimate of $100,000 could range between $95,000 and $110,000. Table 1-2 summarizes the three basic types of cost estimates. TABLE 1-2 Types of cost estimates 97

98 The number and type of cost estimates vary by application area. For example, the Association for the Advancement of Cost Engineering (AACE) International identifies five types of cost estimates for construction projects: order of magnitude, conceptual, preliminary, definitive, and control. The main point is that estimates are usually done at various stages of a project and should become more accurate as time progresses. In addition to creating cost estimates, it is also important to provide supporting details for the estimates. The supporting details include the ground rules and assumptions used in creating the estimate, a description of the project (scope statement, WBS, and so on) used as a basis for the estimate, and details on the cost estimation tools and techniques used to create the estimate. These supporting details should make it easier to prepare an updated estimate or similar estimate as needed. A cost management plan is a document that describes how the organization will manage cost variances on the project. For example, if a definitive cost estimate provides the basis for evaluating supplier cost proposals for all or part of a project, the cost management plan describes how to respond to proposals that are higher or lower than the estimates. Some organizations assume that a cost proposal within 10 percent of the estimate is acceptable and only negotiate items that are more than 10 percent higher or 20 percent lower than the estimated costs. Another important consideration in preparing cost estimates is labour costs, because a large percentage of total project costs are often labour costs. Many organizations estimate the number of people or hours they need by department or skill over the life cycle of a project. 98

99 Cost Estimation Tools and Techniques As you can imagine, developing a good cost estimate is difficult. Fortunately, there are several tools and techniques available to assist in creating one. Commonly used tools and techniques include analogous cost estimating, bottom-up estimating, parametric modelling, the cost of quality, project management estimating software, vendor bid analysis, and reserve analysis. Analogous estimates, also called top-down estimates, use the actual cost of a previous, similar project as the basis for estimating the cost of the current project. This technique requires a good deal of expert judgment and is generally less costly than others are, but it is also less accurate. Analogous estimates are most reliable when the previous projects are similar in fact, not just in appearance. In addition, the groups preparing cost estimates must have the needed expertise to determine whether certain parts of the project will be more or less expensive than analogous projects. For example, estimators often try to find a similar project and then customize/modify it for known differences. However, if the project to be estimated involves a new programming language or working with a new type of hardware or network, the analogous estimate technique could easily result in too low an estimate. Bottom-up estimates involve estimating individual work items or activities and summing them to get a project total. It is sometimes referred to as activity-based costing. The size of the individual work items and the experience of the estimators drive the accuracy of the estimates. If a detailed WBS is available for a project, the project manager could have each person responsible for a work package develop his or her own cost estimate for that work package, or at least an estimate of the amount of resources required. Someone in the financial area of an organization often provides resource cost rates, such as labour rates or costs per pound of materials, which can be entered into project management software to calculate costs. The software automatically calculates information to create cost estimates for each level of the WBS and finally for the entire project. Using smaller work items increases the accuracy of the cost estimate because the people assigned to do the work develop the cost estimate instead of someone unfamiliar with the work. The drawback with bottom-up estimates is that they are usually time-intensive and therefore expensive to develop. Parametric modelling uses project characteristics (parameters) in a mathematical model to estimate project costs. A parametric model might provide an estimate of $50 per line of code for 99

100 a software development project based on the programming language the project is using, the level of expertise of the programmers, the size and complexity of the data involved, and so on. Parametric models are most reliable when the historical information that was used to create the model is accurate, the parameters are readily quantifiable, and the model is flexible in terms of the size of the project. For example, in the 1980s, engineers at McDonnell Douglas Corporation (now part of Boeing) developed a parametric model for estimating aircraft costs based on a large historical database. The model included the following parameters: the type of aircraft (fighter aircraft, cargo aircraft, or passenger aircraft), how fast the plane would fly, the thrust-to-weight ratio of the engine, the estimated weights of various parts of the aircraft, the number of aircraft produced, the amount of time available to produce them, and so on. In contrast to this sophisticated model, some parametric models involve very simple heuristics or rules of thumb. For example, a large office automation project might use a ballpark figure of $10,000 per workstation based on a history of similar office automation projects developed during the same time period. Parametric models that are more complicated are usually computerized. In practice, many people find that using a combination or hybrid approach involving analogous, bottom up, and/or parametric modelling provides the best cost estimates. Typical Problems with Information Technology Cost Estimates Although there are many tools and techniques to assist in creating project cost estimates, many information technology project cost estimates are still very inaccurate, especially those involving new technologies or software development. Tom DeMarco, a well-known author on software development, suggests four reasons for these inaccuracies and some ways to overcome them. Estimates are done too quickly. Developing an estimate for a large software project is a complex task requiring a significant amount of effort. Many estimates must be done quickly and before clear system requirements have been produced. Before fully understanding what information really needed in the system, someone would have to create a ROM estimate and budgetary estimates for the project. Rarely are the more precise, later estimates less than the earlier estimates for information technology projects. It is important to remember that estimates are done at various stages of the project, and project managers need to explain the rationale for each estimate. 100

101 Lack of estimating experience. The people who develop software cost estimates often do not have much experience with cost estimation, especially for large projects. There is also not enough accurate, reliable project data available on which to base estimates. If an organization uses good project management techniques and develops a history of keeping reliable project information, including estimates, it should help improve the organization s estimates. Enabling information technology people to receive training and mentoring on cost estimating will also improve cost estimates. Human beings are biased toward underestimation. For example, senior information technology professionals or project managers might make estimates based on their own abilities and forget that many junior people will be working on a project. Estimators might also forget to allow for extra costs needed for integration and testing on large information technology projects. It is important for project managers and top management to review estimates and ask important questions to make sure the estimates are not biased. Management desires accuracy. Management might ask for an estimate, but really wants a more accurate number to help them create a bid to win a major contract or get internal funding. It is important for project managers to help develop good cost and schedule estimates and to use their leadership and negotiation skills to stand by those estimates. It is also important to be cautious with initial estimates. Top management never forgets the first estimate and rarely, if ever, remembers how approved changes affect the estimate. It is a neverending and crucial process to keep top management informed about revised cost estimates. It should be a formal process, albeit a possibly painful one. Empirical Estimation Techniques Empirical estimation techniques are based on making an educated guess of the project parameters. While using this technique, prior experience with development of similar products is helpful. Although empirical estimation techniques are based on common sense, different activities involved in estimation have been formalized over the years. Two popular empirical estimation techniques are: Expert judgment technique and Delphi cost estimation. Expert Judgment Technique Expert judgment is one of the most widely used estimation techniques. In this approach, an expert makes an educated guess of the problem size after analyzing the problem thoroughly. 101

102 Usually, the expert estimates the cost of the different components (i.e. modules or subsystems) of the system and then combines them to arrive at the overall estimate. However, this technique is subject to human errors and individual bias. Also, it is possible that the expert may overlook some factors inadvertently. Further, an expert making an estimate may not have experience and knowledge of all aspects of a project. For example, he may be conversant with the database and user interface parts but may not be very knowledgeable about the computer communication part. A more refined form of expert judgment is the estimation made by group of experts. Estimation by a group of experts minimizes factors such as individual oversight, lack of familiarity with a particular aspect of a project, personal bias, and the desire to win contract through overly optimistic estimates. However, the estimate made by a group of experts may still exhibit bias on issues where the entire group of experts may be biased due to reasons such as political considerations. Also, the decision made by the group may be dominated by overly assertive members. Delphi cost estimation Delphi cost estimation approach tries to overcome some of the shortcomings of the expert judgment approach. Delphi estimation is carried out by a team comprising of a group of experts and a coordinator. In this approach, the coordinator provides each estimator with a copy of the software requirements specification (SRS) document and a form for recording his cost estimate. Estimators complete their individual estimates anonymously and submit to the coordinator. In their estimates, the estimators mention any unusual characteristic of the product which has influenced his estimation. The coordinator prepares and distributes the summary of the responses of all the estimators, and includes any unusual rationale noted by any of the estimators. Based on this summary, the estimators re-estimate. This process is iterated for several rounds. However, no discussion among the estimators is allowed during the entire estimation process. The idea behind this is that if any discussion is allowed among the estimators, then many estimators may easily get influenced by the rationale of an estimator who may be more experienced or senior. After the completion of several iterations of estimations, the coordinator takes the responsibility of compiling the results and preparing the final estimate. 102

103 5.5 SUMMARY Project cost management is a traditionally weak area of information technology projects. Information technology project managers must acknowledge the importance of cost management and take responsibility for understanding basic cost concepts, cost estimating, budgeting, and cost control. Project managers must understand several basic principles of cost management in order to be effective in managing project costs. Important concepts include profits and profit margins, life cycle costing, cash flow analysis, sunk costs, and learning curve theory. Estimating costs is a very important part of project cost management. There are several types of cost estimates, including rough order of magnitude (ROM), budgetary, and definitive. Each type of estimate is done during different stages of the project life cycle, and each has a different level of accuracy. There are several tools and techniques for developing cost estimates, including analogous estimating, bottom-up estimating, parametric modelling, and computerized tools. 5.6 KEYWORDS Actual cost, Analogous estimate, Bottom-up estimate, Cash flow analysis, Contingency reserves, Indirect costs, Intangible costs, Life cycle costing, Parametric modelling, Sunk costs, Tangible costs, Top-down estimates. 5.7 QUESTIONS 1. Discuss why many information technology professionals may overlook project cost management and how this might affect completing projects within budget. 2. Explain some of the basic principles of cost management, such as profits, life cycle costs, tangible and intangible costs and benefits, direct and indirect costs, reserves, and so on. 3. Give examples of when you would prepare rough order of magnitude (ROM), budgetary, and definitive cost estimates for an information technology project. 4. Give an example of how you would use each of the following techniques for creating a cost estimate: analogous, parametric, and bottom-up. 5. Briefly explain the empirical cost estimation technique. 103

104 5.8 EXERCISE 1. Create a cost estimate/model for building a new, state-of-the-art multimedia classroom for your organization within the next six months. The classroom should include 20 high-end personal computers with appropriate software for your organization, a network server, Internet access for all machines, an instructor station, and a projection system. Be sure to include personnel costs associated with the project management for this project. Document the assumptions you made in preparing the estimate and provide explanations for key numbers. 5.9 REFERENCE 19. Information Technology Project Management: Kathy Schwalbe, International Student Edition, Thomson Course Technology, Software Project Management: Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill. 21. Basics of Software Project Management: NIIT, Prentice-Hall of India, Software Project Management in Practice: Pankaj Jalote, Pearson Education, Software Project Management A Concise Study: S.A.Kelkar, Revised Edition, Prentice- Hall of India, Microsoft Office Project 2003 Bible: Elaine Marmel, Wiley Publishing Inc. 104

105 UNIT 6 PROJECT COST ESTIMATION MODEL STRUCTURE 6.0 Objectives 6.1 COCOMO Model 6.2 Cost Budgeting 6.3 Cost Control 6.4 Software to Assist in Cost Management 6.5 Summary 6.6 Keywords 6.7 Questions 6.8 Exercise 6.9 Reference 6.0 OBJECTIVES After studying this unit, you will be able to: Discuss the COCOMO cost estimation model. Explain the processes involved in cost budgeting and preparing a cost estimate and budget for an information technology project. Discuss the benefits of earned value management to assist in cost control. Describe how project management software can assist in project cost management. 6.1 THE COCOMO MODEL A number of algorithmic models have been proposed as the basis for estimating the effort, schedule and costs of a software project. These are conceptually similar but use different parameter values. The COCOMO model is an empirical model that was derived by collecting 105

106 data from a large number of software projects. These data were analysed to discover formulae that were the best fit to the observations. These formulae link the size of the system and product, project and team factors to the effort to develop the system. It is worth to discuss the COCOMO model because of the following reasons: It is well documented, available in the public domain and supported by public domain and commercial tools. It has been widely used and evaluated in a range of organisations. It has a long pedigree from its first instantiation in 1981 (Boehm, 1981), through a refinement tailored to Ada software development (Boehm and Royce, 1989), to its most recent version, COCOMO II, published in 2000 (Boehm, et al., 2000). The COCOMO models are comprehensive with a large number of parameters that each can take a range of values. The first version of the COCOMO model (COCOMO 81) was a three-level model where the levels corresponded to the detail of the analysis of the cost estimate. The first level (basic) provided an initial rough estimate; the second level modified this using a number of project and process multipliers; and the most detailed level produced estimates for different phases of the project. Organic, Semidetached and Embedded software projects Boehm postulated that any software development project can be classified into one of the following three categories based on the development complexity: organic, semidetached, and embedded. In order to classify a product into the identified categories, Boehm not only considered the characteristics of the product but also those of the development team and development environment. Roughly speaking, these three product classes correspond to application, utility and system programs, respectively. Normally, data processing programs are considered to be application programs. Compilers, linkers, etc., are utility programs. Operating systems and real-time system programs, etc. are system programs. System programs interact directly with the hardware and typically involve meeting timing constraints and concurrent processing. Boehm s [1981] definition of organic, semidetached, and embedded systems are elaborated below. 106

107 Organic: A development project can be considered of organic type, if the project deals with developing a well understood application program, the size of the development team is reasonably small, and the team members are experienced in developing similar types of projects. Semidetached: A development project can be considered of semidetached type, if the development consists of a mixture of experienced and inexperienced staff. Team members may have limited experience on related systems but may be unfamiliar with some aspects of the system being developed. Embedded: A development project is considered to be of embedded type, if the software being developed is strongly coupled to complex hardware, or if the stringent regulations on the operational procedures exist. Basic COCOMO Model The basic COCOMO model gives an approximate estimate of the project parameters. The basic COCOMO estimation model is given by the following expressions: Effort = a х (KLOC) a 2 PM 1 Tdev = b x (Effort) b 2 Months 1 Where KLOC is the estimated size of the software product expressed in Kilo Lines of Code, a, 1 a, b, b are constants for each category of software products, Tdev is the estimated time to develop the software, expressed in months, Effort is the total effort required to develop the software product, expressed in person months (PMs). The effort estimation is expressed in units of person-months (PM). It is the area under the personmonth plot (as shown in Figure 1). It should be carefully noted that an effort of 100 PM does not imply that 100 persons should work for 1 month nor does it imply that 1 person should be employed for 100 months, but it denotes the area under the person-month curve (as shown in Figure 1). 107

108 Figure 1: Person-Month Curve According to Boehm, every line of source text should be calculated as one LOC irrespective of the actual number of instructions on that line. Thus, if a single instruction spans several lines (say n lines), it is considered to be nloc. The values of a, a, b, b for different categories of products (i.e. organic, semidetached, and embedded) as given by Boehm [1981] are summarized below. He derived the above expressions by examining historical data collected from a large number of actual projects. Estimation of development effort For the three classes of software products, the formulas for estimating the effort based on the code size are shown below: Organic: Effort = 2.4(KLOC) 1.05 PM Semi-detached: Effort = 3.0(KLOC) 1.12 PM Embedded: Effort = 3.6(KLOC) 1.20 PM Estimation of development time For the three classes of software products, the formulas for estimating the development time based on the effort are given below: Organic: Tdev = 2.5(Effort) 0.38 Months Semi-detached: Tdev = 2.5(Effort) 0.35 Months Embedded: Tdev = 2.5(Effort) 0.32 Months 108

109 From the effort estimation, the project cost can be obtained by multiplying the required effort by the manpower cost per month. But, implicit in this project cost computation is the assumption that the entire project cost is incurred on account of the manpower cost alone. In addition to manpower cost, a project would incur costs due to hardware and software required for the project and the company overheads for administration, office space, etc. It is important to note that the effort and the duration estimations obtained using the COCOMO model are called as nominal effort estimate and nominal duration estimate. The term nominal implies that if anyone tries to complete the project in a time shorter than the estimated duration, then the cost will increase drastically. But, if anyone completes the project over a longer period of time than the estimated, then there is almost no decrease in the estimated cost value. Example: Assume that the size of an organic type software product has been estimated to be 32,000 lines of source code. Assume that the average salary of software engineers be Rs. 15,000/- per month. Determine the effort required to develop the software product and the nominal development time. From the basic COCOMO estimation formula for organic software: Effort = 2.4 х (32) 1.05 = 91 PM Nominal development time = 2.5 х (91) 0.38 = 14 months Cost required to develop the product = 14 х 15,000 = Rs. 210,000/- Intermediate COCOMO model The basic COCOMO model assumes that effort and development time are functions of the product size alone. However, a host of other project parameters besides the product size affect the effort required to develop the product as well as the development time. Therefore, in order to obtain an accurate estimation of the effort and project duration, the effect of all relevant parameters must be taken into account. The intermediate COCOMO model recognizes this fact and refines the initial estimate obtained using the basic COCOMO expressions by using a set of 15 cost drivers (multipliers) based on various attributes of software development. For example, if modern programming practices are used, the initial estimates are scaled downward by 109

110 multiplication with a cost driver having a value less than 1. If there are stringent reliability requirements on the software product, this initial estimate is scaled upward. Boehm requires the project manager to rate these 15 different parameters for a particular project on a scale of one to three. Then, depending on these ratings, he suggests appropriate cost driver values which should be multiplied with the initial estimate obtained using the basic COCOMO. In general, the cost drivers can be classified as being attributes of the following items: Product: The characteristics of the product that are considered include the inherent complexity of the product, reliability requirements of the product, etc. Computer: Characteristics of the computer that are considered include the execution speed required, storage space required etc. Personnel: The attributes of development personnel that are considered include the experience level of personnel, programming capability, analysis capability, etc. Development Environment: Development environment attributes capture the development facilities available to the developers. An important parameter that is considered is the sophistication of the automation (CASE) tools used for software development. Complete COCOMO model A major shortcoming of both the basic and intermediate COCOMO models is that they consider a software product as a single homogeneous entity. However, most large systems are made up several smaller sub-systems. These sub-systems may have widely different characteristics. For example, some sub-systems may be considered as organic type, some semidetached, and some embedded. Not only that the inherent development complexity of the subsystems may be different, but also for some subsystems the reliability requirements may be high, for some the development team might have no previous experience of similar development, and so on. The complete COCOMO model considers these differences in characteristics of the subsystems and estimates the effort and development time as the sum of the estimates for the individual subsystems. The cost of each subsystem is estimated separately. This approach reduces the margin of error in the final estimate. The following development project can be considered as an example application of the complete COCOMO model. A distributed Management Information System (MIS) product for an 110

111 organization having offices at several places across the country can have the following subcomponents: Database part Graphical User Interface (GUI) part Communication part Of these, the communication part can be considered as embedded software. The database part could be semi-detached software, and the GUI part organic software. The costs for these three components can be estimated separately, and summed up to give the overall cost of the system. 6.2 COST BUDGETING Determining the project budget involves allocating the project cost estimate to individual work items over time. These work items are based on the activities in the work breakdown structure for the project. The activity cost estimates, basis of estimates, scope baseline, project schedule, resource calendars, contracts, and organizational process assets are all inputs for determining the budget. The main goal of the cost budgeting process is to produce a cost baseline for measuring project performance and project funding requirements. It may also result in project document updates, such as items being added, removed, or modified to the scope statement or project schedule. Most organizations have a well-established process for preparing budgets. For example, many organizations require budget estimates to include the number of full-time equivalent (FTE) staff, often referred to as headcount, for each month of the project. This number provides the basis for estimating total compensation costs each year. Many organizations also want to know the amount of money projected to be paid to suppliers for their labour costs or other purchased goods and services. Other common budget categories include travel, depreciation, rents/leases, and other supplies and expenses. It is important to understand these budget categories before developing an estimate to make sure data is collected accordingly. Organizations use this information to track costs across projects and non-project work and look for ways to reduce costs. They also use the information for legal and tax purposes. 111

112 In addition to providing input for budgetary estimates, cost budgeting provides a cost baseline. A cost baseline is a time-phased budget that project managers use to measure and monitor cost performance. Estimating costs for each major project activity over time provides project managers and top management with a foundation for project cost control, as described in the next section. Cost budgeting, as well as requested changes or clarifications, may result in updates to the cost management plan, a subsidiary part of the project management plan. Cost budgeting also provides information for project funding requirements. For example, some projects have all funds available when the project begins, but others must rely on periodic funding to avoid cash flow problems. If the cost baseline shows that more funds are required in certain months than are expected to be available, the organization must make adjustments to avoid financial problems. 6.3 COST CONTROL Controlling project costs includes monitoring cost performance, ensuring that only appropriate project changes are included in a revised cost baseline, and informing project stakeholders of authorized changes to the project that will affect costs. The project management plan, project funding requirements, work performance data, and organizational process assets are inputs for controlling costs. Outputs of this process are work performance measurements, budget forecasts, organizational process asset updates, change requests, project management plan updates, and product document updates. Several tools and techniques assist in project cost control. As shown in Appendix A, Project 2007 has many cost management features to help you enter budgeted costs, set a baseline, enter actuals, calculate variances, and run various cost reports. In addition to using software, however, there must be some change control system to define procedures for changing the cost baseline. This cost control change system is part of the integrated change control system described in Chapter 4, Project Integration Management. Since many projects do not progress exactly as planned, new or revised cost estimates are often required, as are estimates to evaluate alternate courses of action. Performance review meetings can be a powerful tool for helping to control project costs. People often perform better when they know they must report on their progress. Another very important tool for cost control is performance measurement. Although many 112

113 general accounting approaches are available for measuring cost performance, earned value management (EVM) is a very powerful cost control technique that is unique to the field of project management. Earned Value Management Earned value management (EVM) is a project performance measurement technique that integrates scope, time, and cost data. Given a cost performance baseline, project managers and their teams can determine how well the project is meeting scope, time, and cost goals by entering actual information and then comparing it to the baseline. A baseline is the original project plan plus approved changes. Actual information includes whether or not a WBS item was completed or approximately how much of the work was completed, when the work actually started and ended, and how much it actually cost to do the completed work. In the past, earned value management was used primarily on large government projects. Today, however, more and more companies are realizing the value of using this tool to help control costs. In fact, a discussion by several academic experts in earned value management and a real practitioner revealed the need to clarify how to actually calculate earned value. Earned value management involves calculating three values for each activity or summary activity from a project s WBS. 1. The planned value (PV), also called the budget, is that portion of the approved total cost estimate planned to be spent on an activity during a given period. Table 1 shows an example of earned value calculations. Suppose a project included a summary activity of purchasing and installing a new Web server. Suppose further that, according to the plan, it would take one week and cost a total of $10,000 for the labour hours, hardware, and software involved. The planned value (PV) for that activity that week is, therefore, $10, The actual cost (AC) is the total direct and indirect costs incurred in accomplishing work on an activity during a given period. For example, suppose it actually took two weeks and cost $20,000 to purchase and install the new Web server. Assume that $15,000 of these actual costs was incurred during Week 1 and $5,000 was incurred during Week 2. These amounts are the actual cost (AC) for the activity each week. 113

114 3. The earned value (EV) is an estimate of the value of the physical work actually completed. It is based on the original planned costs for the project or activity and the rate at which the team is completing work on the project or activity to date. The rate of performance (RP) is the ratio of actual work completed to the percentage of work planned to have been completed at any given time during the life of the project or activity. For example, suppose the server installation was halfway completed by the end of Week 1. The rate of performance would be 50 percent (50/100) because by the end of Week 1, the planned schedule reflects that the task should be 100 percent complete and only 50 percent of that work has been completed. In Table 1, the earned value estimate after one week is therefore $5,000. Table 2 summarizes the formulas used in earned value management. Note that the formulas for variances and indexes start with EV, the earned value. Variances are calculated by subtracting the actual cost or planned value from EV, and indexes are calculated by dividing EV by the actual cost or planned value. After you total the EV, AC, and PV data for all activities on a project, you can use the CPI and SPI to project how much it will cost and how long it will take to finish the project based on performance to date. Given the budget at completion and original time estimate, you can divide by the appropriate index to calculate the estimate at completion (EAC) and estimated time to complete, assuming performance remains the same. There are no standard acronyms for the term estimated time to complete or original time estimate. TABLE 1 Earned value calculations for one activity after Week 1 114

115 The earned value calculations in Table 1 are carried out as follows: TABLE 2 Earned value formulas Cost variance (CV) is the earned value minus the actual cost. If cost variance is a negative number, it means that performing the work cost more than planned. If cost variance is a positive number, it means that performing the work cost less than planned. Schedule variance (SV) is the earned value minus the planned value. A negative schedule variance means that it took longer than planned to perform the work, and a positive schedule variance means that it took less time than planned to perform the work. The cost performance index (CPI) is the ratio of earned value to actual cost and can be used to estimate the projected cost of completing the project. If the cost performance index is equal to one, or 100 percent, then the planned and actual costs are equal the costs are exactly as budgeted. If the cost performance index is less than one or less than 100 percent, the project is over budget. If the cost performance index is greater than one or more than 100 percent, the project is under budget. 115

116 The schedule performance index (SPI) is the ratio of earned value to planned value and can be used to estimate the projected time to complete the project. Similar to the cost performance index, a schedule performance index of one, or 100 percent, means the project is on schedule. If the schedule performance index is greater than one or 100 percent, then the project is ahead of schedule. If the schedule performance index is less than one or 100 percent, the project is behind schedule. Note that in general, negative numbers for cost and schedule variance indicate problems in those areas. Negative numbers mean the project is costing more than planned or taking longer than planned. Likewise, CPI and SPI less than one or less than 100 percent also indicate problems. The cost performance index can be used to calculate the estimate at completion (EAC) an estimate of what it will cost to complete the project based on performance to date. Similarly, the schedule performance index can be used to calculate an estimated time to complete the project. You can graph earned value information to track project performance. Figure 2 shows an earned value chart for a one-year project after five months. Note that the actual cost and earned value lines end at five months, since that is the point in time where the data is collected or estimated. The chart includes three lines and two points, as follows: Planned value (PV), the cumulative planned amounts for all activities by month. Note that the planned value line extends for the estimated length of the project and ends at the BAC point. Actual cost (AC), the cumulative actual amounts for all activities by month. Earned value (EV), the cumulative earned value amounts for all activities by month. Budget at completion (BAC), the original total budget for the project, or $100,000 in this example. The BAC point is plotted on the chart at the original time estimate of 12 months. Estimate at completion (EAC), estimated to be $122,308, in this example. This number is calculated by taking the BAC, or $100,000 in this case, and dividing by the CPI, which, in this example, was percent. This EAC point is plotted on the chart at the estimated time to complete of months. This number is calculated by taking the original time estimate, or 12 months in this case, and dividing by the SPI, which in this example was percent. 116

117 FIGURE 2. Earned value chart for project after five months Viewing earned value information in chart form helps you visualize how the project is performing. For example, you can see the planned performance by looking at the planned value line. If the project goes as planned, it will finish in 12 months and cost $100,000. Notice in the example in Figure 2 that the actual cost line is always right on or above the earned value line. When the actual cost line is right on or above the earned value line, costs are equal to or more than planned. The planned value line is pretty close to the earned value line, just slightly higher in the last month. This relationship means that the project has been right on schedule until the last month, when the project fell behind schedule. Top managers overseeing multiple projects often like to see performance information in a graphical form such as the earned value chart in Figure 2. Earned value charts allow you to see how projects are performing quickly. If there are serious cost and schedule performance problems, top management may decide to terminate projects or take other corrective action. The estimates at completion (EAC) are important inputs to budget decisions, especially if total funds are limited. Earned value management is an important technique because, when used effectively, it helps top management and project managers evaluate progress and make sound management decisions. 117

118 6.4 SOFTWARE TO ASSIST IN PROJECT COST MANAGEMENT Most organizations use software to assist in various activities related to project cost management. Spreadsheets are a common tool for cost estimating, cost budgeting, and cost control. Many companies also use more sophisticated and centralized financial applications software to provide important cost-related information to accounting and finance personnel. This section focuses specifically on how you can use project management software in cost management. Project management software can be a very helpful tool during each project cost management process. It can help you study overall project information or focus on tasks that are over a specified cost limit. You can use the software to assign costs to resources and tasks, prepare cost estimates, develop cost budgets, and monitor cost performance. Project 2007 has several standard cost reports: cash flow, budget, over budget tasks, over budget resources, and earned value reports. For several of these reports, you must enter percentage completion information and actual costs, just as you need this information when manually calculating earned value or other analyses. Although Microsoft Project 2007 has a fair amount of cost management features, many information technology project managers use other tools to manage cost information; they do not know that they can use Project 2007 for cost management or they simply do not track costs based on a WBS, as most project management software does. As with most software packages, users need training to use the software effectively and understand the features available. Instead of using dedicated project management software for cost management, some information technology project managers use company accounting systems; others use spreadsheet software to achieve more flexibility. Project managers who use other software often do so because these other systems are more generally accepted in their organizations and more people know how to use them. In order to improve project cost management, several companies have developed methods to link data between their project management software and their main accounting software systems. As with using any software, however, managers must make sure that the data is accurate and up-to-date and ask pertinent questions before making any major decisions. 118

119 6.5 SUMMARY Algorithmic cost modelling uses a mathematical formula to predict project costs based on estimates of the project size, the number of software engineers, and other process and product factors. An algorithmic cost model can be built by analysing the costs and attributes of completed projects and finding the closest fit formula to actual experience. The COCOMO costing model is a well-developed algorithmic cost model that takes project, product, hardware and personnel attributes into account when formulating a cost estimate. It also includes a means of estimating development schedules. Determining the budget involves allocating costs to individual work items over time. It is important to understand how particular organizations prepare budgets so estimates are made accordingly. Controlling costs includes monitoring cost performance, reviewing changes, and notifying project stakeholders of changes related to costs. Many basic accounting and finance principles relate to project cost management. Earned value management is an important method used for measuring project performance. Earned value management integrates scope, cost, and schedule information. Several software products assist with project cost management. Project 2007 has many cost management features, including earned value management. Enterprise project management software can help managers evaluate data on multiple projects. 6.6 KEYWORDS Algorithmic cost modelling, Actual cost, COCOMO model, Cost budgeting, Cost baseline, Cost variance, Cost performance index, Earned value, Planned value, Schedule variance, Schedule performance index. 6.7 QUESTIONS 1. How is software projects classified according to Boehm? Explain with examples. 2. What is COCOMO model? Explain how software cost is estimated using COCOMO. 3. Briefly describe the three types of COCOMO model. 119

120 4. Explain what happens during the process to determine the project budget. 5. Explain how earned value management (EVM) can be used to control costs and measure project performance and speculate as to why it is not used more often. 6. What are some general rules of thumb for deciding if cost variance, schedule variance, cost performance index, and schedule performance index numbers are good or bad? 7. Describe several types of software that project managers can use to support project cost management. 6.8 EXERCISE 2. Create a cost estimate/model for building a new, state-of-the-art multimedia classroom for your organization within the next six months. The classroom should include 20 high-end personal computers with appropriate software for your organization, a network server, Internet access for all machines, an instructor station, and a projection system. Be sure to include personnel costs associated with the project management for this project. Document the assumptions you made in preparing the estimate and provide explanations for key numbers. 6.9 REFERENCE 25. Information Technology Project Management: Kathy Schwalbe, International Student Edition, Thomson Course Technology, Software Project Management: Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill. 27. Basics of Software Project Management: NIIT, Prentice-Hall of India, Software Project Management in Practice: Pankaj Jalote, Pearson Education, Software Project Management A Concise Study: S.A.Kelkar, Revised Edition, Prentice- Hall of India, Fundamentals of Software Engineering: Rajib Mall, Third Edition, PHI, Microsoft Office Project 2003 Bible: Elaine Marmel, Wiley Publishing Inc. 120

121 UNIT 7 PROJECT QUALITY MANAGEMENT STRUCTURE 7.0 Objectives 7.1 Introduction 7.2 Importance of Project Quality Management 7.3 Planning Quality 7.4 Quality Assurance 7.5 Summary 7.6 Keywords 7.7 Questions 7.8 Exercise 7.9 Reference 7.0 OBJECTIVES After studying this unit, you will be able to: Explain the importance of project quality management for information technology products and services. Define project quality management and explain how quality relates to various aspects of information technology projects. Describe quality planning and its relationship to project scope management. Discuss the importance of quality assurance. Discuss how software can assist in project quality management. 121

122 7.1 INTRODUCTION Project quality management is a difficult knowledge area to define. The International Organization for Standardization (ISO) defines quality as the totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs (ISO8042:1994) or the degree to which a set of inherent characteristics fulfils requirements. (ISO9000:2000). Many people spent many hours coming up with these definitions, yet they are still very vague. Other experts define quality based on conformance to requirements and fitness for use. Conformance to requirements means the project s processes and products meet written specifications. For example, if the project scope statement requires delivery of 100 computers with specific processors, memory, and so on, you could easily check whether suitable computers had been delivered. Fitness for use means a product can be used as it was intended. If these computers were delivered without monitors or keyboards and were left in boxes on the customer s shipping dock, the customer might not be satisfied because the computers would not be fit for use. The customer may have assumed that the delivery included monitors and keyboards, unpacking the computers and installation so they would be ready to use. 7.2 IMPORTANCE OF PROJECT QUALITY MANAGEMENT The purpose of project quality management is to ensure that the project will satisfy the needs for which it was undertaken. Recall that project management involves meeting or exceeding stakeholder needs and expectations. The project team must develop good relationships with key stakeholders, especially the main customer for the project, to understand what quality means to them. After all, the customer ultimately decides if quality is acceptable. Many technical projects fail because the project team focuses only on meeting the written requirements for the main products being produced and ignores other stakeholder needs and expectations for the project. For example, the project team should know what successfully delivering 100 computers means to the customer. Quality, therefore, must be on an equal level with project scope, time, and cost. If a project s stakeholders are not satisfied with the quality of the project management or the resulting products of the project, the project team will need to adjust scope, time, and cost to satisfy the 122

123 stakeholder. Meeting only written requirements for scope, time, and cost is not sufficient. To achieve stakeholder satisfaction, the project team must develop a good working relationship with all stakeholders and understand their stated or implied needs. Project quality management involves three main processes: Planning quality includes identifying which quality standards are relevant to the project and how to satisfy those standards. Incorporating quality standards into project design is a key part of quality planning. For an information technology project, quality standards might include allowing for system growth, planning a reasonable response time for a system, or ensuring that the system produces consistent and accurate information. Quality standards can also apply to information technology services. For example, you can set standards for how long it should take to get a reply from a help desk or how long it should take to ship a replacement part for a hardware item under warranty. The main outputs of quality planning are a quality management plan, quality metrics, quality checklists, a process improvement plan, and project document updates. A metric is a standard of measurement. Examples of common metrics include failure rates of products produced, availability of goods and services, and customer satisfaction ratings. Performing quality assurance involves periodically evaluating overall project performance to ensure that the project will satisfy the relevant quality standards. The quality assurance process involves taking responsibility for quality throughout the project s life cycle. Top management must take the lead in emphasizing the roles all employees play in quality assurance, especially senior managers roles. The main outputs of this process are organizational process asset updates, change requests, project management plan updates, and project document updates. Performing quality control involves monitoring specific project results to ensure that they comply with the relevant quality standards while identifying ways to improve overall quality. This process is often associated with the technical tools and techniques of quality management, such as Pareto charts, quality control charts, and statistical sampling. You will learn more about these tools and techniques later in this chapter. The main outputs of quality control include quality control measurements, validated changes, validated 123

124 deliverables, organizational process asset updates, change requests, project management plan updates, and project document updates. Figure 1 provides an overview of the Project Quality Management processes and Figure 2 summarizes these processes and outputs, showing when they occur in a typical project. FIGURE 1 Project Quality Management Overview 124

125 7.3 PLANNING QUALITY FIGURE 2 Project quality management summary Project managers today have a vast knowledge base of information related to quality, and the first step to ensuring project quality management is planning. Quality planning implies the ability to anticipate situations and prepare actions that bring about the desired outcome. The current thrust in modern quality management is the prevention of defects through a program of selecting the proper materials, training and indoctrinating people in quality, and planning a process that ensures the appropriate outcome. In project quality planning, it is important to identify relevant quality standards, such as ISO standards described later in this chapter, for each unique project and to design quality into the products of the project and the processes involved in managing the project. Design of experiments is a quality planning technique that helps identify which variables have the most influence on the overall outcome of a process. Understanding which variables affect outcome is a very important part of quality planning. For example, computer chip designers might want to determine which combination of materials and equipment will produce the most reliable chips at a reasonable cost. You can also apply design of experiments to project management issues such as cost and schedule trade-offs. For example, junior programmers or consultants cost less than senior programmers or consultants, but you cannot expect them to complete the same level of work in the same amount of time. An appropriately designed experiment to compute project costs and durations for various combinations of junior and senior 125

126 programmers or consultants can allow you to determine an optimal mix of personnel, given limited resources. Quality planning also involves communicating the correct actions for ensuring quality in a format that is understandable and complete. In quality planning for projects, it is important to describe important factors that directly contribute to meeting the customer s requirements. Organizational policies related to quality, the particular project s scope statement and product descriptions, and related standards and regulations are all important input to the quality planning process. As mentioned in the discussion of project scope management, it is often difficult to completely understand the performance dimension of information technology projects. Even if the development of hardware, software, and networking technology would stand still for a while, it is often difficult for customers to explain exactly what they want in an information technology project. Important scope aspects of information technology projects that affect quality include functionality and features, system outputs, performance, and reliability and maintainability. Functionality is the degree to which a system performs its intended function. Features are the system s special characteristics that appeal to users. It is important to clarify what functions and features the system must perform, and what functions and features are optional. Mandatory features might be a graphical user interface with icons, menus, online help, and so on. System outputs are the screens and reports the system generates. It is important to define clearly what the screens and reports look like for a system. Can the users easily interpret these outputs? Can users get all of the reports they need in a suitable format? Performance addresses how well a product or service performs the customer s intended use. To design a system with high quality performance, project stakeholders must address many issues. What volumes of data and transactions should the system be capable of handling? How many simultaneous users should the system is designed to handle? What is the projected growth rate in the number of users? What type of equipment must the system run on? How fast must the response time be for different aspects of the system under different circumstances? The system is failing a couple of times a month, and users are unsatisfied with the response time. The project team may not have had specific 126

127 performance requirements or tested the system under the right conditions to deliver the expected performance. Buying faster hardware might address these performance issues. Another performance problem that might be more difficult to fix is the fact that some of the reports are generating inconsistent results. This could be a software quality problem that may be difficult and costly to correct since the system is already in operation. Reliability is the ability of a product or service to perform as expected under normal conditions. In discussing reliability for information technology projects, many people use the term IT service management. Maintainability addresses the ease of performing maintenance on a product. Most information technology products cannot reach 100 percent reliability, but stakeholders must define what their expectations are. Are the users willing to have the system be unavailable several hours a week for system maintenance? Providing help desk support could also be a maintenance function. How fast a response do users expect for help desk support? How often can users tolerate system failure? Are the stakeholders willing to pay more for higher reliability and fewer failures? These aspects of project scope are just a few of the requirement issues related to quality planning. Project managers and their teams need to consider all of these project scope issues in determining quality goals for the project. The main customers for the project must also realize their role in defining the most critical quality needs for the project and constantly communicate these needs and expectations to the project team. Since most information technology projects involve requirements that are not set in stone, it is important for all project stakeholders to work together to balance the quality, scope, time, and cost dimensions of the project. Project managers, however, are ultimately responsible for quality management on their projects. Project managers should be familiar with basic quality terms, standards, and resources. For example, the International Organization for Standardization (ISO) provides information based on inputs from 157 different countries. They have an extensive Web site ( which is the source of ISO 9000 and more than 17,000 international standards for business, government and society. If you are curious where the acronym came from, the word ISO comes from the Greek, meaning equal. IEEE also provides many standards related to quality and has detailed information on their Web site ( 127

128 Quality Planning: Tools and Techniques 1. Cost-Benefit Analysis Quality planning must consider cost-benefits tradeoffs. The primary benefit of meeting quality requirements is less rework, which means higher productivity, lower costs, and increased stakeholder satisfaction. The primary cost of meeting quality requirements is the expense associated with Project Quality Management activities. 2. Benchmarking Benchmarking involves comparing actual or planned project practices to those of other projects to generate ideas for improvement and to provide a basis by which to measure performance. These other projects can be within the performing organization or outside of it, and can be within the same or in another application area. 3. Design of Experiments Design of experiments (DOE) is a statistical method that helps identify which factors may influence specific variables of a product or process under development or in production. It also plays a role in the optimization of products or processes. An example is where an organization can use DOE to reduce the sensitivity of product performance to sources of variations caused by environmental or manufacturing differences. The most important aspect of this technique is that it provides a statistical framework for systematically changing all of the important factors, instead of changing the factors one at a time. The analysis of the experimental data should provide the optimal conditions for the product or process, highlighting the factors that influence the results, and revealing the presence of interactions and synergisms among the factors. For example, automotive designers use this technique to determine which combination of suspension and tires will produce the most desirable ride characteristics at a reasonable cost. 4. Cost of Quality (COQ) Quality costs are the total costs incurred by investment in preventing non conformance to requirements, appraising the product or service for conformance to requirements, and failing to meet requirements (rework). Failure costs are often categorized into internal and external. Failure costs are also called cost of poor quality. 128

129 5. Additional Quality Planning Tools Other quality planning tools are also often used to help better define the situation and help plan effective quality management activities. These include brainstorming, affinity diagrams, force field analysis, nominal group techniques, matrix diagrams, flowcharts, and prioritization matrices. 7.4 QUALITY ASSURANCE Quality assurance includes all of the activities related to satisfying the relevant quality standards for a project. Another goal of quality assurance is continuous quality improvement. Many companies understand the importance of quality assurance and have entire departments dedicated to this area. They have detailed processes in place to make sure their products and services conform to various quality requirements. They also know they must produce those Products and services at competitive prices. To be successful in today s competitive business environment, successful companies develop their own best practices and evaluate other organizations best practices to continuously improve the way they do business. Top management and project managers can have the greatest impact on the quality of projects by doing a good job of quality assurance. Several tools used in quality planning can also be used in quality assurance. Design of experiments, as described under quality planning, can also help ensure and improve product quality. Benchmarking generates ideas for quality improvements by comparing specific project practices or product characteristics to those of other projects or products within or outside the performing organization. An important tool for quality assurance is a quality audit. A quality audit is a structured review of specific quality management activities that help identify lessons learned that could improve performance on current or future projects. In-house auditors or third parties with expertise in specific areas can perform quality audits, and quality audits can be scheduled or random. Industrial engineers often perform quality audits by helping to design specific quality metrics for a project and then applying and analyzing the metrics throughout the project. The two types of standards that may be established as part of the quality assurance process are: 129

130 1. Product standards These standards apply to the software product being developed. They include document standards, such as the structure of requirements documents; documentation standards, such as a standard comment header for an object class definition; and coding standards that define how a programming language should be used. 2. Process standards These standards define the processes that should be followed during software development. They may include definitions of specification, design and validation processes and a description of the documents that should be written in the course of these processes. Product standards apply to the output of the software process and, in many cases, process standards include specific process activities that ensure that product standards are followed. Software standards are important for several reasons: 1. They are based on knowledge about the best or most appropriate practice for the company. This knowledge is often only acquired after a great deal of trial and error. Building it into a standard helps the company avoid repeating past mistakes. Standards capture wisdom that is of value to the organisation. 2. They provide a framework for implementing the quality assurance process. Given that standards encapsulate best practice, quality assurance involves ensuring that appropriate standards have been selected and are used. 3. They assist in continuity where work carried out by one person is taken up and continued by another. Standards ensure that all engineers within an organisation adopt the same practices. Consequently, learning effort when starting new work is reduced. The development of software engineering project standards is a difficult and time consuming process. National and international bodies such as the US DoD, ANSI, BSI, NATO and the IEEE have been active in the production of standards. These are general standards that can be applied across a range of projects. Bodies such as NATO and other defence organisations may require that their own standards are followed in software contracts. National and international standards have been developed covering software engineering terminology, programming languages such as Java and C++, notations such as charting symbols, 130

131 procedures for deriving and writing software requirements, quality assurance procedures, and software verification and validation processes (IEEE, 2003). Quality assurance teams that are developing standards for a company should normally base their organisational standards on national and international standards. Using these standards as a starting point, the quality assurance team should draw up a standards handbook. This should define the standards that are needed by their organisation. Examples of standards that might be included in such a handbook are shown in Figure 3. Software engineers sometimes consider standards to be bureaucratic and irrelevant to the technical activity of software development. This is particularly likely when the standards require tedious form filling and work recording. Although they usually agree about the general need for standards, engineers often find good reasons why standards are not necessarily appropriate to their particular project. Figure 3 Product and process standards To avoid these problems, quality managers who set the standards need to be adequately resourced and should take the following steps: 1. Involve software engineers in the selection of product standards. They should understand why standards have been designed and so are more likely to be committed to these standards. The standards document should not simply state a standard to be followed but should include a rationale of why particular standardisation decisions have been made. 131

132 2. Review and modify standards regularly to reflect changing technologies. Once standards are developed, they tend to be enshrined in a company standards handbook, and management is often reluctant to change them. A standards handbook is essential but it should evolve to reflect changing circumstances and technology. 3. Provide software tools to support standards wherever possible. Clerical standards are the cause of many complaints because of the tedious work involved in implementing them. If tool support is available, you don t need much extra effort to follow the software development standards. Process standards may cause difficulties if an impractical process is imposed on the development team. Different types of software need different development processes. There is no point in prescribing a particular way of working if it is inappropriate for a project or project team. Each project manager should therefore have the authority to modify process standards according to individual circumstances. However, standards that relate to product quality and the post-delivery process should be changed only after careful consideration. The project manager and the quality manager can avoid the problems of inappropriate standards by careful quality planning early in the project. They should decide which of the standards in the handbook should be used without change, which should be modified and which should be ignored. New standards may have to be created in response to a particular project requirement. For example, standards for formal specifications may be required if these have not been used in previous projects. As the team gains experience with them, you should plan to modify and extend these new standards. 7.5 SUMMARY Many news headlines regarding the poor quality of information technology projects demonstrate that quality is a serious issue. Several mission-critical information technology systems have caused deaths, and quality problems in many business systems have resulted in major financial losses. Customers are ultimately responsible for defining quality. Important quality concepts include satisfying stated or implied stakeholder needs, conforming to requirements, and delivering items that are fit for use. 132

133 Project quality management includes planning quality, performing quality assurance, and performing quality control. Quality planning identifies which quality standards are relevant to the project and how to satisfy them. Quality assurance involves evaluating overall project performance to ensure that the project will satisfy the relevant quality standards. Quality control includes monitoring specific project results to ensure that they comply with quality standards and identifying ways to improve overall quality. 7.6 KEYWORDS Benchmarking, Conformance, Cost of quality, Defect, Features, Fitness for use, Maintainability, Project quality management, Quality assurance, Quality audit, Quality planning, Reliability, 7.7 QUESTIONS 1. What is meant by project quality? Discuss its importance. 2. What are the main processes included in project quality management? 3. Give the overview of project quality management. 4. What is meant by quality planning? Explain in brief. 5. Describe the important scope aspects of IT projects that affect quality. 6. How do functionality, system outputs, performance, reliability, and maintainability requirements affect quality planning? 7. Discuss about the tools and techniques used for quality planning. 8. What is meant by quality assurance? Discuss the types of standards associated with quality assurance process. 9. What are benchmarks, and how can they assist in performing quality assurance? 10. Describe typical benchmarks associated with a college or university. 7.8 EXERCISE 1. Assume your organization wants to hire new instructors for your project management course. Develop a list of quality standards that you could use in making this hiring decision. 133

134 2. Review the concepts in this unit related to improving the quality of software. Write a two page paper describing how you could apply these concepts to software development projects. 7.9 REFERENCE 32. Information Technology Project Management: Kathy Schwalbe, International Student Edition, Thomson Course Technology, Software Project Management: Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill. 34. Basics of Software Project Management: NIIT, Prentice-Hall of India, Software Project Management in Practice: Pankaj Jalote, Pearson Education, Software Project Management A Concise Study: S.A.Kelkar, Revised Edition, Prentice- Hall of India, Microsoft Office Project 2003 Bible: Elaine Marmel, Wiley Publishing Inc. 134

135 UNIT 8 QUALITY MANAGEMENT TOOLS STRUCTURE 8.0 Objectives 8.1 Performing Quality Control 8.2 Tools and Techniques for Quality Control 8.3 Software to Assist Project Quality Management 8.4 Summary 8.5 Keywords 8.6 Questions 8.7 Exercise 8.8 Reference 8.0 OBJECTIVES After studying this unit, you will be able to: Explain the main outputs of the quality control process. Discuss the tools and techniques for quality control, such as the Seven Basic Tools of Quality, statistical sampling, Six Sigma, and testing. Discuss how software can assist in project quality management. 8.1 PERFORMING QUALITY CONTROL Many people only think of quality control when they think of quality management. Perhaps it is because there are many popular tools and techniques in this area. Before describing some of these tools and techniques, it is important to distinguish quality control from quality planning and quality assurance. 135

136 Although one of the main goals of quality control is to improve quality, the main outcomes of this process are acceptance decisions, rework, and process adjustments. Acceptance decisions determine if the products or services produced as part of the project will be accepted or rejected. If they are accepted, they are considered to be validated deliverables. If project stakeholders reject some of the products or services produced as part of the project, there must be rework. Rework is action taken to bring rejected items into compliance with product requirements or specifications or other stakeholder expectations. Rework often results in requested changes and validated defect repair, resulting from recommended defect repair or corrective or preventive actions. Rework can be very expensive, so the project manager must strive to do a good job of quality planning and quality assurance to avoid this need. Process adjustments correct or prevent further quality problems based on quality control measurements. Process adjustments are often found by using quality control measurements, and they often result in updates to the quality baseline, organization process assets, and the project management plan. 8.2 TOOLS AND TECHNIQUES FOR QUALITY CONTROL Quality control includes many general tools and techniques. This section describes the Seven Basic Tools of Quality, statistical sampling, and Six Sigma and discusses how they can be applied to information technology projects. The section concludes with a discussion on testing, since information technology projects use testing extensively to ensure quality. The following seven tools are known as the Seven Basic Tools of Quality: Cause-and-effect diagrams: Cause-and-effect diagrams trace complaints about quality problems back to the responsible production operations. In other words, they help you find the root cause of a problem. They are also known as fishbone or Ishikawa diagrams, named after their creator, Kaoru Ishikawa. You can also use the technique known as the 5 whys, where you repeatedly ask the question Why? (five is a good rule of thumb) to help peel away the layers of symptoms 136

137 that can lead to the root cause of a problem. These symptoms can be branches on the cause-and-effect diagram. Figure 1 provides an example of a cause-and-effect diagram. Notice that it resembles the skeleton of a fish, hence the name fishbone diagram. This fishbone diagram lists the main areas that could be the cause of the problem: the systems hardware, the user s hardware or software, or the user s training. This figure describes two of these areas, the individual user s hardware and training, in more detail. For example, using the 5 whys, you could first ask why the users cannot get into the system, then why they keep forgetting their passwords, why they did not reset their passwords, why they did not check a box to save a password, and so on. The root cause of the problem would have a significant impact on the actions taken to solve the problem. If many users could not get into the system because their computers did not have enough memory, the solution might be to upgrade memory for those computers. If many users could not get into the system because they forgot their passwords, there might be a much quicker, less expensive solution. FIGURE 1 Sample cause-and-effect diagram Control charts: A control chart is a graphic display of data that illustrates the results of a process over time. Control charts allow you to determine whether a process is in control 137

138 or out of control. When a process is in control, any variations in the results of the process are created by random events. Processes that are in control do not need to be adjusted. When a process is out of control, variations in the results of the process are caused by non random events. When a process is out of control, you need to identify the causes of those non random events and adjust the process to correct or eliminate them. For example, Figure 2 provides an example of a control chart for a process that manufactures 12-inch rulers. Assume that these are wooden rulers created by machines on an assembly line. Each point on the chart represents a length measurement for a ruler that comes off the assembly line. The scale on the vertical axis goes from to These numbers represent the lower and upper specification limits for the ruler. In this case, this would mean that the customer for the rulers has specified that all rulers purchased must be between and inches long, or 12 inches plus or minus 0.10 inches. The lower and upper control limits on the quality control chart are and inches, respectively. This means the manufacturing process is designed to produce rulers between and inches long. Looking for and analyzing patterns in process data is an important part of quality control. You can use quality control charts and the seven run rule to look for patterns in data. The seven run rule states that if seven data points in a row are all below the mean, above the mean, or are all increasing or decreasing, then the process needs to be examined for non-random problems. FIGURE 2 Sample control chart 138

139 In Figure 2, data points that violate the seven run rule are starred. Note that you include the first point in a series of points that are all increasing or decreasing. In the ruler manufacturing process, these data points may indicate that a calibration device may need adjustment. For example, the machine that cuts the wood for the rulers might need to be adjusted or the blade on the machine might need to be replaced. Run chart: A run chart displays the history and pattern of variation of a process over time. It is a line chart that shows data points plotted in the order in which they occur. You can use run charts to perform trend analysis to forecast future outcomes based on historical results. For example, trend analysis can help you analyze how many defects have been identified over time and see if there are trends. Figure 3 shows a sample run chart, charting the number of defects each month for three different types of defects. Notice that you can easily see the patterns of Defect 1 continuing to increase over time, Defect 2 decreasing the first several months and then holding steady, and Defect 3 fluctuating each month. FIGURE 3 Sample run chart Scatter diagram: A scatter diagram helps to show if there is a relationship between two variables. The closer data points are to a diagonal line, the more closely the two variables are related. For example, Figure 4 provides a sample scatter diagram that compare user satisfaction ratings of the EIS system to the age of respondents to see if there is a relationship. They might find that younger users are less satisfied with the system, for example, and make decisions based on that finding. 139

140 FIGURE 4 Sample scatter diagram Histograms: A histogram is a bar graph of a distribution of variables. Each bar represents an attribute or characteristic of a problem or situation, and the height of the bar represents its frequency. For example, Scott Daniels might ask the Help Desk to create a histogram to show how many total complaints they received each week related to the EIS system. Figure 5 shows a sample histogram. FIGURE 5 Sample histogram Pareto charts: A Pareto chart is a histogram that can help you identify and prioritize problem areas. The variables described by the histogram are ordered by frequency of occurrence. Pareto charts help you identify the vital few contributors that account for most quality problems in a system. Pareto analysis is sometimes referred to as the rule, meaning that 80 percent of problems are often due to 20 percent of the causes. For 140

141 example, suppose there was a detailed history of user complaints about the EIS. The project team could create a Pareto chart based on that data, as shown in Figure 6. FIGURE 6 Sample Pareto chart Notice that login problems are the most frequent user complaint, followed by the system locking up, the system being too slow, the system being hard to use, and the reports being inaccurate. The first complaint accounts for 55 percent of the total complaints. The first and second complaints have a cumulative percentage of almost 80 percent, meaning these two areas account for 80 percent of the complaints. Therefore, the company should focus on making it easier to log in to the system to improve quality, since the majority of complaints fall under that category. The company should also address why the system locks up. Because Figure 6 shows that inaccurate reports are a problem that is rarely mentioned, the project manager should investigate who made this complaint before spending a lot of effort on addressing that potentially critical problem with the system. The project manager should also find out if complaints about the system being too slow were actually due to the user not being able to log in or the system locking up. Flowcharts: Flowcharts are graphic displays of the logic and flow of processes that help you analyze how problems occur and how processes can be improved. They show activities, decision points, and the order of how information is processed. Figure 7 provides a simple example of a flowchart that shows the process a project team might use for accepting or rejecting deliverables. 141

142 FIGURE 7 Sample Flowchart Statistical Sampling Statistical sampling is a key concept in project quality management. Members of a project team who focus on quality control must have a strong understanding of statistics, but other project team members need to understand only the basic concepts. These concepts include statistical sampling, certainty factor, standard deviation, and variability. Standard deviation and variability are fundamental concepts for understanding quality control charts. This section briefly describes these concepts and describes how a project manager might apply them to information technology projects. Statistical sampling involves choosing part of a population of interest for inspection. For example, suppose a company wants to develop an electronic data interchange (EDI) system for handling data on invoices from all of its suppliers. Assume also that in the past year, the total number of invoices was 50,000 from 200 different suppliers. It would be very time consuming and expensive to review every single invoice to determine data requirements for the new system. Even if the system developers did review all 200 invoice forms from the different suppliers, the data might be entered differently on every form. It is impractical to study every member of a 142

143 population, such as all 50,000 invoices, so statisticians have developed techniques to help determine an appropriate sample size. If the system developers used statistical techniques, they might find that by studying only 100 invoices, they would have a good sample of the type of data they would need in designing the system. The size of the sample depends on how representative you want the sample to be. A simple formula for determining sample size is: Sample size = 0.25 * (certainty factor / acceptable error) 2 The certainty factor denotes how certain you want to be that the data sampled will not include variations that do not naturally exist in the population. You calculate the certainty factor from tables available in statistics books. Table 1 shows some commonly used certainty factors. TABLE 1 Commonly used certainty factors For example, suppose the developers of the EDI system described earlier would accept a 95 percent certainty that a sample of invoices would contain no variation unless it was present in the population of total invoices. They would then calculate the sample size as: Sample size = 0.25 * (1.960 / 0.05) 2 = 384 If the developers wanted 90 percent certainty, they would calculate the sample size as: Sample size = 0.25 * (1.645 / 0.10) 2 = 68 If the developers wanted 80 percent certainty, they would calculate the sample size as: Sample size = 0.25 * (1.281 / 0.20) 2 = 10 Assume the developers decide on 90 percent for the certainty factor. Then they would need to examine 68 invoices to determine the type of data the EDI system would need to capture. 143

144 Six Sigma The work of many project quality experts contributed to the development of today s Six Sigma principles. There has been some confusion in the past few years about the term Six Sigma. This section summarizes recent information about this important concept and explains how organizations worldwide use Six Sigma principles to improve quality, decrease costs, and better meet customer needs. In their book, The Six Sigma Way, authors Peter Pande, Robert Neuman, and Roland Cavanagh define Six Sigma as a comprehensive and flexible system for achieving, sustaining and maximizing business success. Six Sigma is uniquely driven by close understanding of customer needs, disciplined use of facts, data, and statistical analysis, and diligent attention to managing, improving, and reinventing business processes. Six Sigma s target for perfection is the achievement of no more than 3.4 defects, errors, or mistakes per million opportunities. An organization can apply the Six Sigma principles to the design and production of a product, a help desk, or other customer-service process. Projects that use Six Sigma principles for quality control normally follow a five-phase improvement process called DMAIC (pronounced de-may-ick), which stands for Define, Measure, Analyze, Improve, and Control. DMAIC is a systematic, closed-loop process for continued improvement that is scientific and fact based. The following are brief descriptions of each phase of the DMAIC improvement process: 1. Define: Define the problem/opportunity, process, and customer requirements. Important tools used in this phase include a project charter, a description of customer requirements, process maps, and Voice of the Customer (VOC) data. Examples of VOC data include complaints, surveys, comments, and market research that represent the views and needs of the organization s customers. 2. Measure: Define measures, then collect, compile, and display data. Measures are defined in terms of defects per opportunity. 3. Analyze: Scrutinize process details to find improvement opportunities. A project team working on a Six Sigma project, normally referred to as a Six Sigma team, investigates and verifies data to prove the suspected root causes of quality problems and substantiates 144

145 the problem statement. An important tool in this phase is the fishbone or Ishikawa diagram, as described earlier in this unit. 4. Improve: Generate solutions and ideas for improving the problem. A final solution is verified with the project sponsor, and the Six Sigma team develops a plan to pilot test the solution. The Six Sigma team reviews the results of the pilot test to refine the solution, if needed, and then implements the solution where appropriate. 5. Control: Track and verify the stability of the improvements and the predictability of the solution. Control charts are one tool used in the control phase. How is Six Sigma Quality Control Unique? How do using Six Sigma principles differ from using previous quality control initiatives? Many people remember other quality initiatives from the past few decades such as Total Quality Management (TQM) and Business Process Reengineering (BPR), to name a few. The origins of many Six Sigma principles and tools are found in these previous initiatives; however, there are several new ideas included in Six Sigma principles that help organizations improve their competitiveness and bottom-line results. Below are a few of these principles: Using Six Sigma principles is an organization-wide commitment. CEOs, top managers, and all levels of employees in an organization that embraces Six Sigma principles (often referred to as a Six Sigma organization) have seen remarkable improvements due to its use. There are often huge training investments, but these investments pay off as employees practice Six Sigma principles and produce higher quality goods and services at lower costs. Six Sigma training normally follows the belt system, similar to a karate class in which students receive different colour belts for each training level. In Six Sigma training, those in the Yellow Belt category receive the minimum level of training, which is normally two to three full days of Six Sigma training for project team members who work on Six Sigma projects on a part-time basis. Those in the Green Belt category usually participate in two to three full weeks of training. Those in the Black Belt category normally work on Six Sigma projects full-time and attend four to five full weeks of training. Project managers are often Black Belts. The Master Black Belt category describes experienced Black Belts who act as technical resources and mentors to people with lower-level belts. 145

146 Organizations that successfully implement Six Sigma principles have the ability and willingness to adopt two seemingly contrary objectives at the same time. Authors James Collins and Jerry Porras describe this as the We can do it all or Genius of the And approach in their book, Built to Last. For example, Six Sigma organizations believe that they can be creative and rational, focus on the big picture and minute details, reduce errors and get things done faster, and make customers happy and make a lot of money. Six Sigma is not just a program or a discipline to organizations that have benefited from it. Six Sigma is an operating philosophy that is customer-focused and strives to drive out waste, raise levels of quality, and improve financial performance at breakthrough levels. A Six Sigma organization sets high goals and uses the DMAIC improvement process to achieve extraordinary quality improvements. Many organizations do some of what now fits under the definition of Six Sigma, and many Six Sigma principles are not brand-new. What is new is its ability to bring together many different themes, concepts, and tools into a coherent management process that can be used on an organization-wide basis. Six Sigma and Statistics An important concept in Six Sigma is improving quality by reducing variation. The term sigma means standard deviation. Standard deviation measures how much variation exists in a distribution of data. A small standard deviation means that data clusters closely around the middle of a distribution and there is little variability among the data. A large standard deviation means that data is spread out around the middle of the distribution and there is relatively greater variability. Statisticians use the Greek symbol (sigma) to represent the standard deviation. 146

147 FIGURE 8 Normal distribution and standard deviation Figure 8 shown above provides an example of a normal distribution a bell-shaped curve that is symmetrical regarding the mean or average value of the population (the data being analyzed). In any normal distribution, 68.3 percent of the population is within one standard deviation (1σ) of the mean, 95.5 percent of the population is within two standard deviations (2σ), and 99.7 percent of the population is within three standard deviations (3σ) of the mean. Standard deviation is a key factor in determining the acceptable number of defective units found in a population. Table 2 illustrates the relationship between sigma, the percentage of the population within that sigma range, and the number of defective units per billion. Note that this table shows that being plus or minus, six sigma in pure statistical terms means only two defective units per billion. TABLE 2 Sigma and defective units Based on Motorola s original work on Six Sigma in the 1980s, the convention used for Six Sigma is a scoring system that accounts for more variation in a process than you would typically 147

148 find in a few weeks or months of data gathering. In other words, time is an important factor in determining process variations. Table 3 shows the Six Sigma conversion table applied to Six Sigma projects. The yield represents the number of units handled correctly through the process steps. A defect is any instance where the product or service fails to meet customer requirements. Because most products or services have multiple customer requirements, there can be several opportunities to have a defect. For example, suppose a company is trying to reduce the number of errors on customer billing statements. There could be several errors on a billing statement due to a misspelled name, incorrect address, wrong date of service, calculation error, and so on. There might be 100 opportunities for a defect to occur on one billing statement. Instead of measuring the number of defects per unit or billing statement, Six Sigma measures the number of defects based on the number of opportunities. TABLE 3 Sigma conversion table As you can see, the Six Sigma conversion table shows that a process operating at six sigma means there are no more than 3.4 defects per million opportunities. However, most organizations today use the term six sigma project in a broad sense to describe projects that will help them in achieving, sustaining, and maximizing business success through better business processes. Another term you may hear being used in the telecommunications industry is six 9s of quality. Six 9s of quality is a measure of quality control equal to 1 fault in 1 million opportunities. In the telecommunications industry, it means percent service availability or 30 seconds of down time a year. This level of quality has also been stated as the target goal for the number of errors in a communications circuit, system failures, or errors in lines of code. To achieve six 9s 148

149 of quality requires continual testing to find and eliminate errors or enough redundancy and backup equipment in systems to reduce the overall system failure rate to that low a level. Testing Many information technology professionals think of testing as a stage that comes near the end of information technology product development. Instead of putting serious effort into proper planning, analysis, and design of information technology projects, some organizations rely on testing just before a product ships to ensure some degree of quality. In fact, testing needs to be done during almost every phase of the systems development life cycle, not just before the organization ships or hands over a product to the customer. Figure 9 shows one way of portraying the systems development life cycle. This example includes 17 main tasks involved in a software development project and shows their relationship to each other. For example, every project should start by initiating the project, conducting a feasibility study, and then performing project planning. The figure then shows that the work involved in preparing detailed requirements and the detailed architecture for the system can be performed simultaneously. The oval-shaped phases represent actual tests or tasks, which will include test plans to help ensure quality on software development projects. Several of the phases in Figure 9 include specific work related to testing. A unit test is done to test each individual component (often a program) to ensure that it is as defect-free as possible. Unit tests are performed before moving onto the integration test. Integration testing occurs between unit and system testing to test functionally grouped components. It ensures a subset(s) of the entire system works together. System testing tests the entire system as one entity. It focuses on the big picture to ensure that the entire system is working properly. User acceptance testing is an independent test performed by end users prior to accepting the delivered system. It focuses on the business fit of the system to the organization, rather than technical issues. 149

150 FIGURE 9 Testing tasks in the software development life cycle To help improve the quality of software development projects, it is important for organizations to follow a thorough and disciplined testing methodology. System developers and testers must also establish a partnership with all project stakeholders to make sure the system meets their needs and expectations and the tests are done properly. Testing alone, however, cannot always solve software defect problems, according to Watts S. Humphrey, a renowned expert on software quality and Fellow at Carnegie Mellon s Software Engineering Institute. He believes that the traditional code/test/fix cycle for software development is not enough. As code gets more complex, the number of defects missed by testing increases and becomes the problem not just of testers, but also of paying customers. Humphrey says that, on average, programmers introduce a defect for every nine or ten lines of code, and the finished software, after all testing, contains about five to six defects per thousand lines of code. Although there are many different definitions, Humphrey defines a software defect as anything 150

151 that must be changed before delivery of the program. Testing does not sufficiently prevent software defects because the number of ways to test a complex system is huge. In addition, users will continue to invent new ways to use a system that its developers never considered, so certain functionalities may never have been tested or even included in the system requirements. Humphrey suggests that people rethink the software development process to provide no potential defects when you enter system testing. This means that developers must be responsible for providing error-free code at each stage of testing. Humphrey teaches a development process where programmers measure and track the kinds of errors they commit so they can use the data to improve their performance. He also acknowledges that top management must support developers by letting them self direct their work. Programmers need to be motivated and excited to do high-quality work and have some control over how they do it. ISO Standards The International Organization for Standardization (ISO) is a network of national standards institutes that work in partnership with international organizations, governments, industries, businesses, and consumer representatives. ISO 9000, a quality system standard developed by the ISO, is a three-part, continuous cycle of planning, controlling, and documenting quality in an organization. ISO 9000 provides minimum requirements needed for an organization to meet its quality certification standards. The ISO 9000 family of international quality management standards and guidelines has earned a global reputation as the basis for establishing quality management systems. The ISO s Web site ( includes testimonials from many business leaders throughout the world explaining the benefits of following these standards. A government official in Malaysia believes that the universally accepted ISO 9000 standard can contribute significantly to improving quality and enhancing development of an excellent work culture. ISO 9000 leads to a more systematic management of quality and provides a means of consolidating quality management systems in public service. Managers in the United Kingdom say that ISO 9000 has become a firmly established cornerstone of their organizations drive toward quality improvement. It leads to substantial cost savings and contributes strongly to customer satisfaction. 151

152 A Brazilian newspaper reported that following ISO 9000 helped its home delivery service improve so much that the complaints dropped to a mere 0.06 percent of the total copies distributed ISO continues to offer standards to provide a framework for the assessment of software processes. The overall goals of a standard are to encourage organizations interested in improving quality of software products to employ proven, consistent, and reliable methods for assessing the state of their software development processes. They can also use their assessment results as part of coherent improvement programs. One of the outcomes of assessment and consequent improvement programs is reliable, predictable, and continuously improving software processes. The contributions of several quality experts, quality awards, and quality standards are important parts of project quality management. The Project Management Institute was proud to announce in 1999 that their certification department had become the first certification department in the world to earn ISO 9000 certification, and that the PMBOK Guide had been recognized as an international standard. Emphasizing quality in project management helps ensure that projects produce products or services that meet customer needs and expectations. 8.3 SOFTWARE TO ASSIST PROJECT QUALITY MANAGEMENT This unit provides examples of several tools and techniques used in project quality management. Software can be used to assist with several of these tools and techniques. For example, you can create charts and diagrams from many of the Seven Basic Tools of Quality using spreadsheet and charting software. You can use statistical software packages to help you determine standard deviations and perform many types of statistical analyses. You can create Gantt charts using project management software to help you plan and track work related to project quality management. There are also several specialized software products to assist people with managing Six Sigma projects, creating quality control charts, and assessing maturity levels. Project teams need to decide what types of software will help them manage their particular projects. As you can see, quality itself is a very broad topic, and it is only one of the nine project management knowledge areas. Project managers must focus on defining how quality relates to 152

153 their specific projects and ensure that those projects will satisfy the needs for which they were undertaken. 8.4 SUMMARY There are many tools and techniques related to project quality management. The Seven Basic Tools of Quality include cause-and-effect diagrams, control charts, run charts, scatter diagrams, histograms, Pareto charts, and flowcharts. Statistical sampling helps define a realistic number of items to include in analyzing a population. Six Sigma helps companies improve quality by reducing defects. Standard deviation measures the variation in data. Testing is very important in developing and delivering high-quality information technology products. Six Sigma principles and ISO 9000 have helped organizations emphasize the importance of improving quality. There are several types of software available to assist in project quality management. It is important for project teams to decide which software will be most helpful for their particular projects. 8.5 KEYWORDS cause-and-effect diagram, conformance, control chart, defect, DMAIC, flowchart, histogram, integration testing, Ishikawa diagram, ISO 9000, mean, Pareto analysis, Pareto chart, quality control, run chart, scatter diagram, Six Sigma, standard deviation, statistical sampling, system testing, unit test. 8.6 QUESTIONS 1. What are the three main categories of outputs for quality control? 2. Provide examples of when you would use the Seven Basic Tools of Quality on an information technology project. 3. What is meant by statistical sampling? Explain how this concept is used for project quality management. 4. What is Six Sigma? Describe the five phase improvement process involved in Six Sigma for controlling software quality. 5. What is testing? Discuss the importance of various levels of testing. 153

154 6. What are ISO standards? How are they useful for quality control? Explain. 7. Describe three types of software that can assist in project quality management. 8.7 EXERCISE 1. Review the information in this chapter about Six Sigma principles and Six Sigma organizations. 2. Brainstorm ideas for a potential Six Sigma project that could improve quality on your campus, at your workplace, or in your community. Write a two-page paper describing one project idea and explain why it would be a Six Sigma project. Review and discuss how you could use the DMAIC process on this project. 3. Review the concepts in this unit related to improving the quality of software. Write a two page paper describing how you could apply these concepts to software development projects. 8.8 REFERENCE 38. Information Technology Project Management: Kathy Schwalbe, International Student Edition, Thomson Course Technology, Software Project Management: Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill. 40. Basics of Software Project Management: NIIT, Prentice-Hall of India, Software Project Management in Practice: Pankaj Jalote, Pearson Education, Software Project Management A Concise Study: S.A.Kelkar, Revised Edition, Prentice- Hall of India, Microsoft Office Project 2003 Bible: Elaine Marmel, Wiley Publishing Inc. 154

155 Module-3 UNIT 9: Human Resource Management Structure: 9.0 Objectives 9.1 Introduction 9.2 Project Human Resources Management 9.3 Organizational Planning 9.4 Summary 9.5 Keywords 9.6 Unit-end exercises and answers 9.7 Suggested readings 9.0 OBJECTIVES In this unit, you will be able to know: 1. To create and utilize an able and motivated workforce, to accomplish the basic organizational goals. 2. To establish and maintain sound organizational structure and desirable working relationships among all the members of the organization. 3. To secure the integration of individual or groups within the organization by co-ordination of the individual and group goals with those of the organization. 4. To create facilities and opportunities for individual or group development so as to match it with the growth of the organization. 5. To attain an effective utilization of human resources in the achievement of organizational goals. 155

156 6. To identify and satisfy individual and group needs by providing adequate and equitable wages, incentives, employee benefits and social security and measures for challenging work, prestige, recognition, security, status. 7. To maintain high employees morale and sound human relations by sustaining and improving the various conditions and facilities. 8. To strengthen and appreciate the human assets continuously by providing training and development programs. 9. To consider and contribute to the minimization of socio-economic evils such as unemployment, under-employment, inequalities in the distribution of income and wealth and to improve the welfare of the society by providing employment opportunities to women and disadvantaged sections of the society. 10. To provide an opportunity for expression and voice management. 11. To provide fair, acceptable and efficient leadership. 12. To provide facilities and conditions of work and creation of favorable atmosphere for maintaining stability of employment. 9.1 INTRODUCTION Human resource management (HRM, or simply HR) is the management process of an organization's workforce, or human resources. It is responsible for the attraction, selection, training, assessment, and rewarding of employees, while also overseeing organizational leadership and culture and ensuring compliance with employment and labor laws. In circumstances where employees desire and are legally authorized to hold a collective bargaining agreement, HR will also serve as the company's primary liaison with the employees' representatives. HR is a product of the human relations movement of the early 20th century, when researchers began documenting ways of creating business value through the strategic management of the workforce. The function was initially dominated by transactional work, such as payroll and benefits administration, but due to globalization, company consolidation, technological advancement, and further research, HR now focuses on strategic initiatives like mergers and acquisitions, talent management, succession planning, industrial and labour relations, and diversity and inclusion. 156

157 In startup companies, HR's duties may be performed by trained professionals. In larger companies, an entire functional group is typically dedicated to the discipline, with staff specializing in various HR tasks and functional leadership engaging in strategic decision making across the business. To train practitioners for the profession, institutions of higher education, professional associations, and companies themselves have created programs of study dedicated explicitly to the duties of the function. Academic and practitioner organizations likewise seek to engage and further the field of HR, as evidenced by several field-specific publications. In the current global work environment, all global companies are focused on retaining the talent and knowledge held by the workforce. All companies are focused on lowering the employee turnover and preserving knowledge. New hiring not only entails a high cost but also increases the risk of the newcomer not being able to replace the person who was working in that position before. HR departments also strive to offer benefits that will appeal to workers, thus reducing the risk of losing knowledge. 9.2 PROJECT HUMAN RESOURCES MANAGEMENT Project human resource management includes the processes required to make the most effective use of the people involved with a project. Human resource management includes all project stakeholders: sponsors, customers, project team members, support staff, suppliers supporting the project, and so on. Human resource management includes the following four processes: 1. Developing the human resource plan involves identifying and documenting project roles, responsibilities, and reporting relationships. The main output of this process is a human resource plan. 2. Acquiring the project team involves getting the needed personnel assigned to and working on the project. Key outputs of this process are project staff assignments, resource calendars, and project management plan updates. 3. Developing the project team involves building individual and group skills to enhance project performance. Team-building skills are often a challenge for many project managers. The main outputs of this process are team performance assessments and enterprise environmental factors updates. 157

158 4. Managing the project team involves tracking team member performance, motivating team members, providing timely feedback, resolving issues and conflicts, and coordinating changes to help enhance project performance. Outputs of this process include enterprise environmental factors updates, organizational process assets updates, change requests, and project management plan updates. Figure summarizes these processes and outputs, showing when they occur in a typical project. Figure: Project human resource management summary KEYS TO MANAGING PEOPLE Industrial-organizational psychologists and management theorists have devoted extensive research and thought to the field of managing people at work. Psychosocial issues that affect how people work and how well they work include motivation, influence and power, and effectiveness. This section reviews the contributions of Abraham Maslow, Frederick Herzberg, David McClelland, and Douglas McGregor to an understanding of motivation; the work of H. J. Thamhain and D. L. Wilemon on influencing workers and reducing conflict; the effect of power on project teams; and Stephen Covey s work on how people and teams can become more effective. Finally, you look at some implications and recommendations for project managers. 158

159 Motivation Theories Psychologists, managers, coworkers, teachers, parents, and most people in general still struggle to understand what motivates people to do what they do. Intrinsic motivation causes people to participate in an activity for their own enjoyment. For example, some people love to read, write, or play an instrument because it makes them feel good. Extrinsic motivation causes people to do something for a reward or to avoid a penalty. For example, some young children would prefer not to play an instrument, but they do because they receive a reward or avoid a punishment for doing so. Why do some people require no external motivation to produce high-quality work while others require significant external motivation to perform routine tasks? Why can t you get someone who is extremely productive at work to do simple tasks at home? Humankind will continue to try to answer these types of questions. A basic understanding of motivational theory will help anyone who works or lives with other people to understand themselves and others. Maslow s Hierarchy of Needs Abraham Maslow, a highly respected psychologist who rejected the dehumanizing negativism of psychology in the 1950s, is best known for developing a hierarchy of needs. In the 1950s, proponents of Sigmund Freud s psychoanalytic theory promoted the idea that human beings were not the masters of their destiny and that all their actions were governed by unconscious processes dominated by primitive sexual urges. During the same period, behavioral psychologists saw human beings as controlled by the environment. Maslow argued that both schools of thought failed to recognize unique qualities of human behavior: love, self-esteem, belonging, self-expression, and creativity. He argued that these unique qualities enable people to make independent choices, which give them full control of their destiny. Figure 2 shows the basic pyramid structure of Maslow s hierarchy of needs, which states that people s behaviors are guided or motivated by a sequence of needs. At the bottom of the hierarchy are physiological needs. Once physiological needs are satisfied, safety needs guide behavior. Once safety needs are satisfied, social needs come to the forefront, and so on up the hierarchy. The order of these needs and their relative sizes in the pyramid are significant. Maslow suggests that each level of the hierarchy is a prerequisite for the levels above. For example, a person cannot consider self-actualization without first addressing basic needs of 159

160 security and safety. People in an emergency, such as a flood or hurricane, do not worry about personal growth. Personal survival will be their main motivation. Once a particular need is satisfied, however, it no longer serves as a potent motivator of behavior. FIGURE 2 Maslow s hierarchy of needs The bottom four needs in Maslow s hierarchy physiological, safety, social, and esteemare referred to as deficiency needs, and the highest level, self-actualization, is considered a growth need. Only after meeting deficiency needs can people act upon growth needs. Selfactualized people are problem-focused, have an appreciation for life, are concerned about personal growth, and are able to have peak experiences. Most people working on an IT project probably have their basic physiological and safety needs met. If someone has a sudden medical emergency or is laid off from work, however, physiological and safety needs will move to the forefront. The project manager needs to understand each team member s motivation, especially with regard to social, esteem, and selfactualization or growth needs. Team members who are new to a company and city might be motivated by social needs. To address social needs, some companies organize gatherings and social events for new workers. Other project members may find these events to be an invasion of personal time that they would rather spend with their friends and family, or working on an advanced degree. Maslow s hierarchy conveys a message of hope and growth. People can work to control their own destinies and naturally strive to satisfy higher needs. Successful project managers know they must focus on meeting project goals, but they also must understand team members personal goals and needs to provide appropriate motivation and maximize team performance. 160

161 Herzberg s Motivation-Hygiene Theory Frederick Herzberg is best known for distinguishing between motivational factors and hygiene factors when considering motivation in work settings. He referred to factors that cause job satisfaction as motivators and factors that could cause dissatisfaction as hygiene factors. Herzberg was the head of Case Western University s psychology department, and he wrote the book Work and the Nature of Man in 1966 and a famous Harvard Business Review article, One More Time: How Do You Motivate Employees? in Herzberg analyzed the factors that affected productivity among a sample of 1,685 employees. Popular beliefs at the time were that work output was most improved through larger salaries, more supervision, or a more attractive work environment. According to Herzberg, these hygiene factors would cause dissatisfaction if not present, but would not motivate workers to do more if present. Today, professionals might also expect employers to provide health benefits, training, and a computer or other equipment required to perform their jobs. Herzberg found that people were motivated to work mostly by feelings of personal achievement and recognition. Motivators, Herzberg concluded, included achievement, recognition, the work itself, responsibility, advancement, and growth, as shown in Table 9. TABLE 1 Examples of Herzberg s hygiene factors and motivators In his book, Herzberg explained why companies could not instill motivation by attempting to use positive factors such as reducing time spent at work, increasing wages, offering fringe benefits, and providing human relations and sensitivity training. He argued that people want to actualize themselves by being able to use their creativity and work on challenging projects. They need stimuli to grow and advance, in accordance with Maslow s hierarchy of 161

162 needs. Factors such as achievement, recognition, responsibility, advancement, and growth produce job satisfaction and are work motivators. McClelland s Acquired-Needs Theory David McClelland proposed that a person s specific needs are acquired or learned over time and shaped by life experiences. The main categories of acquired needs include achievement, affiliation, and power. Normally, one or two of these needs are dominant in people. Achievement: People who have a high need for achievement (nach) seek to excel, and tend to avoid both low-risk and high-risk situations to improve their chances for achieving something worthwhile. Achievers need regular feedback and often prefer to work alone or with other high achievers. Managers should give high achievers challenging projects with achievable goals. Achievers should receive frequent performance feedback, and although money is not an important motivator to them, it is an effective form of feedback. Affiliation: People with a high need for affiliation (naff) desire harmonious relationships with other people and need to feel accepted by others. They tend to conform to the norms of their work group and prefer work that involves significant personal interaction. Managers should try to create a cooperative work environment to meet the needs of people with a high need for affiliation. Power: People with a need for power (npow) desire either personal power or institutional power. People who need personal power want to direct others and can be seen as bossy. People who need institutional power or social power want to organize others to further the goals of the organization. Management should provide such employees with the opportunity to manage others, emphasizing the importance of meeting organizational goals. The Thematic Apperception Test (TAT) is a tool to measure the individual needs of different people using McClelland s categories. The TAT presents subjects with a series of ambiguous pictures and asks them to develop a spontaneous story for each picture, assuming they will project their own needs into the story. 162

163 Thamhain and Wilemon s Influence and Power Many people working on a project do not report directly to project managers, and project managers often do not have control over project staff who report to them. For example, people are free to change jobs. If they are given work assignments they do not like, many workers will simply quit or transfer to other departments or projects. H. J. Thamhain and D. L. Wilemon investigated the approaches that project managers use to deal with workers and how those approaches relate to project success. They identified nine influence bases that are available to project managers: 1. Authority: the legitimate hierarchical right to issue orders 2. Assignment: the project manager s perceived ability to influence a worker s later work assignments 3. Budget: the project manager s perceived ability to authorize others use of discretionary funds 4. Promotion: the ability to improve a worker s position 5. Money: the ability to increase a worker s pay and benefits 6. Penalty: the project manager s perceived ability to dispense or cause punishment 7. Work challenge: the ability to assign work that capitalizes on a worker s enjoyment of doing a particular task, which taps an intrinsic motivational factor 8. Expertise: the project manager s perceived special knowledge that others deem important 9. Friendship: the ability to establish friendly personal relationships between the project manager and others. Top management grants authority to the project manager. However, assignment, budget, promotion, money, and penalty influence bases are not automatically available to project managers as part of their position. Others perceptions are important in establishing the usefulness of these influence bases. For example, any manager can influence workers by providing challenging work; the ability to provide challenging work (or take it away) is not a special ability of project managers. In addition, project managers must earn the ability to influence by using expertise and friendship. Thamhain and Wilemon found that projects were more likely to fail when project managers relied too heavily on using authority, money, or penalty to influence people. When project managers used work challenge and expertise to influence people, projects were more 163

164 likely to succeed. The effectiveness of work challenge in influencing people is consistent with Maslow s and Herzberg s research on motivation. The importance of expertise as a means of influencing people makes sense on projects that involve special knowledge, as in most IT projects. Influence is related to the topic of power. Power is the ability to influence behavior to get people to do things they would not otherwise do. Power has a much stronger connotation than influence, especially because it is often used to force people to change their behavior. There are five main types of power, based on French and Raven s classic study, The Bases of Social Power. Coercive power involves using punishment, threats, or other negative approaches to get people to do things they do not want to do. This type of power is similar to Thamhain and Wilemon s influence category called penalty. For example, a project manager can threaten to fire workers or subcontractors to try to get them to change their behavior. If the project manager really has the power to fire people, he or she could follow through on the threat. Recall, however, that influencing by using penalties is correlated with unsuccessful projects. Still, coercive power can be very effective in stopping negative behavior. For example, if students tend to hand in assignments late, an instructor can have a policy in the syllabus for late penalties, such as a 20 percent grade reduction for each day an assignment is late. Legitimate power is getting people to do things based on a position of authority. This type of power is similar to the authority basis of influence. If top management gives project managers organizational authority, they can use legitimate power in several situations. They can make key decisions without involving the project team, for example. Overemphasis on legitimate power or authority also correlates with project failure. Expert power involves using personal knowledge and expertise to get people to change their behavior. People who perceive that project managers are experts in certain situations will follow their suggestions. For example, if a project manager has expertise in working with a particular IT supplier and its products, the project team will be more likely to follow the project manager s suggestions on how to work with that vendor and its products. 164

165 Reward power involves using incentives to induce people to do things. Rewards can include money, status, recognition, promotions, and special work assignments. Many motivation theorists suggest that only certain types of rewards, such as work challenge, achievement, and recognition, truly induce people to change their behavior or work hard. Referent power is based on a person s own charisma. People who have referent power are held in very high regard; others will do what they say based on that regard. People such as Martin Luther King, Jr., John F. Kennedy, and Bill Clinton had referent power. Very few people possess the natural charisma that underlies referent power. It is important for project managers to understand what types of influence and power they can use in different situations. New project managers often overemphasize their position their legitimate power or authority influence especially when dealing with project team members or support staff. They also neglect the importance of reward power or work challenge influence. People often respond much better to a project manager who motivates them with challenging work and provides positive reinforcement for doing a good job. Project managers should understand the basic concepts of influence and power, and should practice using them to their own advantage and to help their teams. 9.3 ORGANIZATIONAL PLANNING An organizational plan is basically a to do list for an organization. It lists out the plan of work, programs, and organizational growth over a period of time six months, a year, five years. They can be pretty simple to create and use. Writing a plan can just mean getting a clear list of the types of work that need to be done, the tasks involved, who is responsible for them, and when they ll be done. Preparing for Organizational Planning Organizational planning is not planning to create an organization. Organizational planning is the process of mapping the project s roles, responsibilities, and reporting relationships to the appropriate people or groups of people. Organizational planning identifies the people involved with the project and determines what their role in the project is, whom they may to report to or receive a report from and what their overall influence on the project work 165

166 is. Consider a project to create a community park. The project manager works for a commercial entity that will complete the project work. She identifies the people responsible for activities within her organization, the designers, engineers, installers, management, and so on. She will also have functional managers to coordinate employees availability, financing to arrange procurement of resources needed for project completion, and senior management to report the status of the project work. The project manager will also work and communicate with government officials for approval of the design, change requests, and overall schedule of the project. There ll be safety issues, landscaping questions, and other concerns that will come up as the project progresses. Finally, the project manager will likely communicate with stakeholders that are not internal to her organization for example, the people that live in the community and enjoy the park, and various government officials. These stakeholders will need to be involved in the planning and design of the park to ensure it satisfies the community s needs. As you can see, organizational planning can involve both internal and external stakeholders. In most projects, organizational planning happens early in the project planning phase but it should be reviewed and adjusted as the environment changes. Organizational planning is all about ensuring the project performs properly in the environment it is working in. Identifying the Project Interfaces Project interfaces are the people and groups the project manager and the project team will work with to complete the project. There are three types of interfaces: Organizational interfaces: These are the folks within the performing organization that the project team will work with to complete the project work. For example, a project to install a centralized, real-time database for customer orders and manufacturing will require the Sales, Finance, Manufacturing, and Information Technology organizational units to be involved. The different organizational units may all be involved throughout the project life, or their level of involvement may fluctuate depending on the project needs. Technical interfaces: The technical interfaces describe the relationship between the project and the technical disciplines input to the project. Consider a project to create a new building. The technical interfaces would include architects, mechanical engineers, 166

167 structural engineers, and others. These interfaces would be involved throughout the project phases-and also between project phases for inspections, change requests, and so on. Interpersonal Interfaces Interpersonal interfaces describe the reporting relationship among the people working on the project. Depending on the nature of the project and the information to be shared, the communication can be informal, such as a hallway meeting, or formal, such as a variance report. Identifying the Staffing Requirements Every project needs people to complete the work. Staffing requirements are the identified roles needed on a project to complete the assigned work. For example, a project to install a new telephone system throughout a campus would require a menagerie of workers with varying skill sets: hardware and software gurus, telephony experts, electricians, installers, and others. The identified staff would be pulled from the resource pool. Any skills gaps would need to be addressed through staff acquisition, additional training, or procurement. Identifying the Project Constraints Constraints limit. When it comes to human resource constraints, the project manager is dealing with any factors that limit options for project completion. This is where creativity comes into play: the project manager must find a way to creatively acquire, schedule, or train the needed resources to complete the project. Common constraints include Organizational structure: Recall the organizational structures: functional, weak matrix, balanced matrix, strong matrix, and projectized? The project manager s authority in the organization is relevant to the organizational structure he is forced to work within. 167

168 Collective bargaining agreements: The contractual agreements between employee groups, unions, or other labor organizations may serve as a constraint on the project. In these instances, there may be additional reporting relationships on the project status, work, and performance on project team members. Project Management Preferences: If a project manager has had success with the organization and management of a project team in the past, the project manager will most likely want to re-create the success by following the same model. Current projects should emulate successful historical projects. Staffing: Based on the competencies and talent of the project team, the assignments to activities are created. Project organization, scheduling, and workflow are often dependent on the abilities of the project team. Procurement: When a particular qualification, skill, or specific person is requested as part of the project requirement, this requirement becomes a constraint on the project. Completing Organizational Planning Organizational planning calls upon the project manager to consider the requirements of the project and the stakeholders involved and how the nature of the project will require the project manager and the project team to interact with the stakeholders. In addition, the project manager has to consider the project team itself and how the team will be managed, led, and motivated to complete the project work according to plan. The goal of organizational planning is to identify and plan for the constraints and opportunities brought about by the nature of the project work, the team s competence, and the demands of the performing organization and stakeholders. There are scores of books written on organizational planning, theory, and project team motivation. The goal of this conversation is to know the essentials to pass the PMP exam. Relying on Templates All projects are somewhat different, but some may resemble historical projects. The resemblance to historical projects allows the project manager to use proven plans as templates for current projects. Specifically, in light of organizational planning, the project manager can use the roles and responsibility matrixes and the reporting structure of historical projects as a model 168

169 for the current project. As a heuristic, current projects should emulate successful historical projects. Applying Human Resource Practices The performing organization will likely have policies and procedures for the project manager to follow. The HR department should specify Job responsibilities Reporting structures The project manager s role and autonomy Policies regarding project team member discipline The definition for customized organizational terms such as coach, mentor, or champion Examining Organizational Planning Results Organizational planning is part of the overall planning processes so it, too, is iterative. The outputs of organizational planning should be reviewed periodically throughout the project to ensure completeness and accuracy. Should events, people, or stakeholders change throughout the project, the following outputs of organizational planning should be updated to reflect the changes. Creating the Role and Responsibility Assignments There are slick definitions for roles and responsibility: Role: Who does what Responsibility: Who decides what The assignment of the roles and responsibilities determines what actions the project manager, project team member, or individual contributor will have in the project. Roles and responsibilities generally support the project scope since this is the required work for the project. An excellent tool that the project manager should create is the Responsibility Assignment Matrix (RAM). A RAM can be high-level-for example, mapping project groups to the high-level components of a WBS, such as architecture, network, or software creation. A RAM can also be detailed specific to the activities within the project work. Figure 1 is an example of a RAM. 169

170 A Responsibility Assignment Matrix can map work to project team members Creating a Staffing Management Plan The staffing management plan details how project team members will be brought onto the project and excused from the project. This subsidiary plan documents the process the project manager is expected to complete to bring new project team members aboard based on the conditions of the project. For example, a project may require an application developer in the third phase of the project. The project manager may have to complete a job description of what the application developer will be responsible for, how their time will be used, and how long the role is needed on the project. HR or other functional managers may have to approve the request. Resource histograms illustrate the demand for labor 170

171 Management may also want to see a resource histogram, as Figure 2 illustrates, so they may plan employees time and activities accordingly. Management may elect to hold off on the launch of a project based on the requirement for resources and the conflict with business cycles or other projects with higher priorities within the organization. Each performing organization will likely have policies and procedures that should be documented, and followed, to bring resources onto the project team. In addition, the organization may have similar ways to excuse project team members from a project once their contribution has been completed. The staffing management plan should Detail how project team members are brought onto and released from the project Account for employees time on the project Use employees as needed, and when needed Remove or reduce worries about employment by communicating the expected need for resources 9.4 SUMMARY HRM is also a strategic and comprehensive approach to managing people and the workplace culture and environment. Effective HRM enables employees to contribute effectively and productively to the overall company direction and the accomplishment of the organization's goals and objectives. HRM is moving away from traditional personnel, administration, and transactional roles, which are increasingly outsourced. HRM is now expected to add value to the strategic utilization of employees and that employee programs impact the business in measurable ways. The new role of HRM involves strategic and HRM metrics and measurements to demonstrate value. 9.5 KEYWORDS HRM Human Resource Management, TAT Thematic Apperception Test, Coercive power, Legitimate power. 9.6 UNIT END EXERCISE AND ANSWERS 1. What is HRM? Explain HRM involvement in project. 171

172 2. What is Organizational Planning? Explain in detail 9.7 SUGGESTED READING 1. Information Technology Project Management Kathy Schwalbe, International Student Edition, THOMSON CourseTechnology, Software Project Management Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill 3. Microsoft Office Project 2003 Bible, Elaine Marmel, Wiley Publishing Inc. 172

173 UNIT 10: CASE STUDY AND ISSUES INVOLVED Structure: 10.0 Objectives 10.1 Staff Acquisition 10.2 Tools and Techniques for staff acquisition 10.3 Output from Staff acquisition 10.4 Case Study 10.5 Team development 10.6 Five issues to be considered in Project Staff Acquisition and Team Development 10.7 Using software to assist Human Resource Management 10.8 Summary 10.9 Keywords Unit-end exercises and answers Suggested readings 10.0 OBJECTIVES At the end this unit you will be able to Explain the need of staff acquisition Understand the issues to be considered in staff acquisition development Elucidate the case studies on software to human management 173

174 10.1 STAFF ACQUISITION Staff acquisition involves getting the human resources needed (individuals or groups) assigned to and working on the project. In most environments, the "best" resources may not be available, and the project management team must take care to ensure that the resources which are available will meet project requirements Inputs to Staff Acquisition Staffing management plan: Regardless of what you do in an organization, a staff is required in order to execute work tasks and activities. If you are a project manager, you need to have an adequate staff for executing your project activities. Just having the required number of staff members for your project will not help you to successfully execute the project activities. These staff members selected for your project should have necessary skills to execute the project responsibilities as well. In addition, they should have the necessary motivation and availability as well. Therefore, staffing of your project should be done methodologically with a proper and accurate plan Understanding the Purpose: Before you start staffing your project, you need to understand the purpose of your project. First of all, you need to understand the business goals for the project and other related objectives. Without you being clear about the end results, you may not be able to staff the best resources for your project. Spend some time brainstorming about your project purpose and then try to understand the related staffing requirements. Understand the different skills required for project execution, in order to understand what kind of staff you want Be Precise: Be precise when you prepare your staffing management plan. Make your staffing plan in black and white. Do not include things just to make the people happy. Always include the truth in your plan in a bold way. Whenever required, emphasize the roles and responsibilities of the staff and organizational policies as well. The workforce should be disciplined in order to execute a project successfully. Therefore, you need to include discipline requirements to the staffing plan as well. 174

175 Use a Good Template: When it comes to articulating the plan, you need to use a good template for that. First of all, there are chances that you can find a suitable one from your organization itself. Talk to your peers and see whether there are templates that they have used in the past. In case if your organization has a knowledge management system, search for a template there. Once you get a good template, articulate everything in simple language. The audience of the plan is the management and the staff. Therefore, articulation should be clear and simple Making the Connection: Connecting with your staff is the key. By properly connecting, you can measure them for their skills and attitude. Interviewing the staff members is the best way to properly engaging with them. By doing this, you can measure their skills and you can see whether they are suitable for your project requirements. For interviews, you can come up with an interview schedule and a set of critical questions you may want to ask. In case there are things you cannot uncover through interviews, ask assistance from HR Training: Before you start staffing for the project, you need to know what skills required for your project. This way, you can measure the skills of your potential staff during the interviews. In most instances, you will not find all the staff members with desired skills. In such cases, you will have to request for trainings from the training department. Get applicable staff members trained on required skills in advance to the project commencement Rewards and Consequences: Staffing management plan should be crystal clear about the staff rewards as well as the consequences. The plan should illustrate the rewards in detail and how a staff member or the entire staff becomes eligible for rewards. As an example, early delivery of projects is rewarded by paying a bonus to the staff members, who are involved in the project. This is one of the best ways to keep the staff motivation and focused on the project activities Considerations: In addition to the above areas, there can be additional considerations. One might be the duration of your staffing requirement. It's very rare that a project will require all the staff during the entire project life cycle. Usually, the staffing requirement varies during different phases of the project. Refer to the following diagram in order to identify the staff variation. 175

176 Usually, during the initial phases of the project, the project requires only a limited number of staff members. When it comes to development or construction, it may need a lot. Again, when it reaches the end, it will require a less number of staff Staffing pool description: When the project management team is able to influence or direct staff assignments, it must consider the characteristics of the potentially available staff. Considerations include, but are not limited to: Previous experience--have the individuals or groups done similar or related work before? Have they done it well? Personal interests--are the individuals or groups interested in working on this project? Personal characteristics--are the individuals or groups likely to work well together as a team? Availability--will the most desirable individuals or groups be available in the necessary time frames? Recruitment practices: One or more of the organizations involved in the project may have policies, guidelines, or procedures governing staff assignments. When they exist, such practices act as a constraint on the staff acquisition process TOOLS AND TECHNIQUES FOR STAFF ACQUISITION Negotiations: Staff assignments must be negotiated on most projects. For example, the project management team may need to negotiate with: 176

177 Responsible functional managers to ensure that the project receives appropriately skilled staff in the necessary time frame. Other project management teams within the performing organization to assign scarce or specialized resources appropriately. The team's influencing skills play an important role in negotiating staff assignments as do the politics of the organizations involved. For example, a functional manager may be rewarded based on staff utilization. This creates an incentive for the manager to assign available staff who may not meet all of the project's requirements Pre-assignment: In some cases, staff may be preassigned to the project. This is often the case when: a) The project is the result of a competitive proposal and specific staff was promised as part of the proposal, b) The project is an internal service project and staff assignments were defined within the project charter Procurement: Project procurement management can be used to obtain the services of specific individuals or groups of individuals to perform project activities. Procurement is required when the performing organization lacks the in-house staff needed to complete the project OUTPUT FROM STAFF ACQUISITION Project staff assigned: The project is staffed when appropriate people have been reliably assigned to work on it. Staff may be assigned full-time, part-time, or variably, based on the needs of the project Project team directory: A project team directory lists all the project team members and other key stakeholders. The directory may be formal or informal, highly detailed or broadly framed, based on the needs of the project. 177

178 10.4 CASE STUDY Resource Assignment After developing a staffing management plan, project managers must work with other people in their organizations to assign personnel to their projects or to acquire additional human resources needed to staff the project. Project managers with strong influencing and negotiating skills are often good at getting internal people to work on their projects. However, the organization must ensure that people are assigned to the projects that best fit their skills and the needs of the organization. The main outputs of this process are project staff assignments, resource availability information, and updates to the staffing management plan. Many project teams also find it useful to create a project team directory. Organizations that do a good job of staff acquisition have good staffing plans. These plans describe the number and type of people who are currently in the organization and the number and type of people anticipated to be needed for the project based on current and upcoming activities. An important component of staffing plans is maintaining a complete and accurate inventory of employees skills. If there is a mismatch between the current mix of people s skills and needs of the organization, it is the project manager s job to work with top management, human resource managers, and other people in the organization to address staffing and training needs. It is also important to have good procedures in place for hiring subcontractors and recruiting new employees. Because the Human Resource department is normally responsible for hiring people, project managers must work with their human resource managers to address any problems in recruiting appropriate people. It is also a priority to address retention issues, especially for IT professionals. One innovative approach to hiring and retaining IT staff is to offer existing employees incentives for helping recruit and retain personnel. For example, several consulting companies give their employees one dollar for every hour worked by a new person they helped recruit. This provides an incentive for current employees to help attract new people and to keep all of them working at the company. Another approach to attract and retain IT professionals is to provide benefits based on personal need. For example, some people might want to work only four days a week or have the option of working a couple of days a week from home. As it becomes more 178

179 difficult to find good IT professionals, organizations must become more innovative and proactive in addressing this issue. It is very important to consider the needs of individuals and the organization when making recruiting and retention decisions and to study the best practices of leading companies in these areas. It is also important to address a growing trend in project team members many of them work in a virtual environment Resource Loading One of the problems or dangers inherent in scheduling processes is that they often do not address the issues of resource utilization and availability. Schedules tend to focus primarily on time rather than both time and resources, which includes people. An important measure of a project manager s success is how well he or she balances the trade-offs among performance, time, and cost. During a period of crisis, it is occasionally possible to add resources-such as additional staff-to a project at little or no cost. Most of the time, however, resolving performance, time, and cost trade-offs entails additional costs to the organization. The project manager s goal must be to achieve project success without increasing the costs or time required to complete the project. The key to accomplishing this goal is effectively managing human resources on the project. Figure-One: Sample resource histogram Once people are assigned to projects, two techniques are available to project managers that help them use project staff most effectively: resource loading and resource leveling. Resource loading refers to the amount of individual resources that an existing schedule requires 179

180 during specific time periods. Resource loading helps project managers understand the demands of a project on the organization s resources and on individual people s schedules. Project managers often use histograms, as shown in Figure 1, to depict period-by-period variations in resource loading. A histogram can be very helpful in determining staffing needs or in identifying staffing problems. A resource histogram can also show when work is being over allocated to a certain person or group. Over allocation means that not enough resources are available to perform the assigned work during a given time period. For example, Figure 2 shows a sample resource histogram created in Microsoft Project. This histogram illustrates how much one person, Joe Franklin, is assigned to work on the project each week. The numbers on the vertical axis represent the percentage of Joe s available time that is allocated for him to work on the project. The top horizontal axis represents time in weeks. Note that Joe Franklin is over allocated most of the time. Figure- Two: Sample histogram showing an over allocated person 180

181 Resource Leveling Resource leveling is a technique for resolving resource conflicts by delaying tasks. It is a form of network analysis in which resource management concerns drive scheduling decisions (start and finish dates). The main purpose of resource leveling is to create a smoother distribution of resource usage. Project managers examine the network diagram for areas of slack or float, and to identify resource conflicts. For example, you can sometimes remove over allocations by delaying noncritical tasks, which does not result in an overall schedule delay. At other times, you will need to delay the project completion date to reduce or remove over allocations. Second, resource leveling may enable project managers to use a just-in-time inventory type of policy for subcontractors or other expensive resources. For example, a project manager might want to level resources for work that must be done by particular subcontractors such as testing consultants. This leveling might allow the project to use four outside consultants full-time to perform testing for four months instead of spreading out the work over more time or using more than four people. The latter approach is usually more expensive. Recall from Chapter 6 that crashing and fast tracking can also be used along with resource concerns to improve a project schedule. Third, resource leveling results in fewer problems for project personnel and accounting departments. Increasing and decreasing labor levels and human resources often produce additional work and confusion. For example, if people with expertise in the same area are only assigned to a project two days a week and they need to work together, then the schedule needs to reflect this need. The Accounting department might complain when subcontractors charge a higher rate for billing less than 20 hours a week on a project. The accountants will remind project managers to strive to get the lowest rates possible. Finally, resource leveling often improves morale. People like to have some stability in their jobs. It is very stressful for people not to know what projects they will be working on from week to week or even from day to day. Project management software can automatically level resources. However, the project manager must be careful in using the results without making adjustments. Automatic leveling often pushes out the project s completion date. Resources may also be reallocated to work at times that are inappropriate with other constraints. To ensure that the leveling is done 181

182 appropriately, a wise project manager would have his or her work checked by a team member who is proficient in using the project management software TEAM DEVELOPMENT Even if a project manager has successfully recruited enough skilled people to work on a project, the project manager must ensure that people can work together as a team to achieve project goals. Many IT projects have talented people working on them, but it takes teamwork to complete most projects successfully. The main goal of team development is to help people work together more effectively to improve project performance. Dr. Bruce Tuckman published his four-stage model of team development in 1965 and modified it to include an additional stage in the 1970s. The Tuckman model describes five stages of team development: 1. Forming involves the introduction of team members; either at the initiation of the team or as new members is introduced. This stage is necessary, but little work is actually achieved. 2. Storming occurs when team members have different opinions for how the team should operate. People test each other, and there is often conflict within the team. 3. Norming is achieved when team members have developed a common working method, and cooperation and collaboration replace the conflict and mistrust of the previous phase. 4. Performing occurs when the emphasis is on reaching the team s goals rather than working on team process. Relationships are settled, and team members are likely to build loyalty toward each other. At this stage, the team is able to manage tasks that are more complex and cope with greater change. 5. Adjourning involves the break-up of the team after it successfully reaches its goals and completes the work. There is an extensive body of literature on team development. This section highlights a few important tools and techniques for team development, including training, teambuilding activities, and reward and recognition systems. 182

183 Training Project managers often recommend that people take specific training courses to improve individual and team development. For example, Sarah from the opening case had gone through training in emotional intelligence and dealing with difficult people. She was familiar with the mirroring technique and felt comfortable using that approach with Ben. Many other people would not have reacted so quickly and effectively in the same situation. If Ben and Sarah did reach agreement on what actions they could take to resolve the F-44 aircraft program s IT problems, it might result in a new project to develop and deliver a new system for Ben s group. If Sarah became the project manager for this new project, she would understand the need for special training in interpersonal skills for specific people in her department and Ben s. Individual team members could take special training classes to improve their personal skills. If Sarah thought the whole project team could benefit from taking training together to learn to work as a team, she could arrange for a special teambuilding session for the entire project team and key stakeholders. It is very important to provide training in a just-in-time fashion. For example, if Sarah were preparing for a technical assignment that required her to learn a new programming language, training to deal with difficult people would not help her much. However, the training was very timely for her new consulting position. Many organizations provide e-learning opportunities for their employees so they can learn specific skills at any time and any place. They have also found that e-learning is sometimes more cost-effective than traditional instructorled training courses. It is important to make sure that the timing and delivery method for the training is appropriate for specific situations and individuals. Organizations have also found that it is often more economical to train current employees in particular areas than it is to hire new people who already possess those skills. Several organizations that have successfully implemented Six Sigma principles have taken a unique and effective approach to training. They only let high-potential employees attend Six Sigma Black Belt training, which is a substantial investment of time and money. In addition, they do not let employees into a particular Black Belt course until the employees have had a potential Six Sigma project approved that relates to their current job. Attendees can then apply the new concepts and techniques they learn in the classes to their jobs. High-potential employees feel rewarded by being picked to take this training, and the 183

184 organization benefits by having these employees implement high-payoff projects because of the training Team-Building Activities Many organizations provide in-house team-building training activities, and many also use services provided by external companies that specialize in this area. Two common approaches to team-building activities include using physical challenges and psychological preference indicator tools. It is important to understand individual needs, including learning styles, past training, and physical limitations, when determining team-building training options. Several organizations have teams go through physically challenging activities to help them develop as a team. Military basic training or boot camps provide one example. Men and women who want to join the military must first finish basic training, which often involves strenuous physical activities such as rappelling off towers, running and marching in full military gear, going through obstacle courses, passing marksmanship training, and mastering survival training. Many organizations use a similar approach by sending teams to special locations where they work together to navigate white water rapids, climb mountains or rocks, and participate in rope courses. Research shows that physical challenges often help teams of strangers to work together more effectively, but it can cause already dysfunctional teams to have even more problems. Even more organizations have teams participate in mental team-building activities in which they learn about themselves, each other, and how to work as a group most effectively. It is important for people to understand and value each other s differences to work effectively as a team. Three common exercises used in mental team building include the Myers-Briggs Type Indicator, Wilson Learning Social Styles Profile, and the DISC Profile Reward and Recognition Systems Another important tool for promoting team development is the use of team-based reward and recognition systems. If management rewards teamwork, they will promote or reinforce the philosophy that people work more effectively in teams. Some organizations offer bonuses, trips, or other rewards to workers that meet or exceed company or project goals. In a project setting, project managers can recognize and reward people who willingly work overtime to meet an aggressive schedule objective or go out of their way to help a 184

185 teammate. Project managers should not reward people who work overtime just to get extra pay or because of their own poor work or planning. Project managers must continually assess their team s performance. When they find areas in which individuals or the entire team can improve, it s their job to find the best way to develop their people and improve performance FIVE ISSUES TO BE CONSIDERED IN PROJECT STAFF ACQUISITION AND TEAM DEVELOPMENT A group is a collection of people who come together because they share something in common. (Solomon, Davidson, and Solomon, 1993). What they share could be as insignificant as desire to get on the next bus that will arrive at a particular stop. A team, however, is a group of people who share a common name, mission, history, set of goals or objectives and expectations. A strategy that can help groups develop into real teams is teambuilding, the process needed to create, maintain, and enrich the development of a group of people into a cohesive unit. Teambuilding exercises are very important in the development of teams that will work together for an extended period of time on a complex project or a series of activities. Teambuilding is not a silver bullet for fixing dysfunctional teams, or assuring that all of your teams will work well. But, teambuilding exercises can be helpful in developing effective teams, if they are selected to enable teams to explore the five critical issues identified in this outline Cohesiveness This term refers to the attractiveness of group membership. Groups are cohesive to the extent that membership in them is positively valued, and members are drawn toward the group. In task oriented (e.g., learning or project) groups, the concept can be differentiated into two sub concepts: social cohesiveness and task cohesiveness. Social cohesiveness refers to the bonds of interpersonal attraction that link group members. Task cohesiveness refers to the way in which skills and abilities of the group members mesh to allow optimal performance. Team building exercises that have a component of fun or play are useful in allowing social cohesiveness to develop. Examples include: designing a team logo, sharing information about first jobs, or participating in activities to discover characteristics that team members have 185

186 in common. To develop task cohesiveness, activities that allow the group members to assess one another s talents, strengths and weaknesses are useful Roles and Norms All groups develop a set of roles and norms over time, whether or not these are explicitly discussed. Norms are the rules governing the behavior of group members. The use of explicitly defined roles enables the group to cope effectively with the requirements of the task. The roles and norms that govern cooperative learning groups are often imposed by the instructor, but that does not preclude a teambuilding exercise in which those roles and norms, as well as some that are specific to a group, are discussed and accepted. An example of a team builder which would help teammates to develop effective norms would be to ask them to develop team ground rules or a Code of Cooperation. A team builder which would help teammates use roles effectively might ask them to select the roles which are most needed to accomplish the task at hand and to assign those roles to team members Communication Effective interpersonal communication is vital to the smooth functioning of any task group. Norms will develop governing communication - do those norms encourage everyone to participate, or do they allow one or two dominant members to claim all the air time? Team building exercises can focus on skill development, communication network design, and norms, but even when the exercise is focused on another issue, communication is happening. Watch it! Shape it! There are many ways of facilitating the learning of effective communication skills. Active listening exercises, practice in giving and receiving feedback, and practice in checking for comprehension of verbal messages are all aimed at developing skills Goal Specification It is very important for group members to have common goals for group achievement, as well as to communicate clearly about individual goals they may have. Some teambuilding sessions consist entirely of goal clarification exercises. The process of clarifying goals may well engage all of the issues on this list. Indeed, shared goals are one of the definitional properties of the concept team. 186

187 A simple, but useful, team building task is to assign a newly formed group the task of producing a mission and goals statement Interdependence This is the issue of how each team member s success is determined, at least in part, by the success of the other members. The structure of the cooperative learning task should be such that it requires positive interdependence: students in a team should sink or swim together. Functioning independently of other group members or competing with them should lead to poor performance for the entire group. Both cooperative learning tasks and teambuilding tasks should have such a structure. A example of a teambuilding exercise designed so that the team becomes aware of, and experiences their interdependence is Desert Survival. In this exercise, teammates individually rank the importance of items they will need to survive after a plane crash in the desert. The team then comes to consensus on the rankings of the items. Team rankings, almost invariably, are more accurate than most individuals rankings USING SOFTWARE TO ASSIST IN HUMAN RESOURCE MANAGEMENT Earlier in this unit, you read that a simple responsibility assignment matrix or histograms are useful tools that can help you effectively manage human resources on projects. You can use several different software packages, including spreadsheets or project management software such as Microsoft Project 2010, to create matrixes and histograms. Many people do not realize that Project 2010 provides a variety of human resource management tools, some of which include assigning and tracking resources, resource leveling, resource usage reports, over allocated resource reports, and to-do lists. You can use Project 2010 to assign resources such as equipment, materials, facilities, and people to tasks. Project 2010 enables you to allocate individual resources to individual projects or to pool resources and share them across multiple projects. By defining and assigning resources in Project 2010, you can: Keep track of resources through stored information and reports on resource assignments. Identify potential resource shortages that could force a project to miss scheduled deadlines and possibly extend the duration of a project. 187

188 Identify underutilized resources and reassign them, which may enable you to shorten a project s schedule and reduce costs. Use automated leveling to make level resources easier to manage. Just as many project management professionals are not aware of the powerful cost management features of Project 2010, many are also unaware of its powerful human resource management features. The Microsoft Enterprise Project Management Solution provides additional human resource management capabilities. You can also purchase adding software for Microsoft products or purchase software from other companies to manage your project s human resources. With the aid of this software, project managers can have more information available in useful formats to help them decide how to manage human resources most effectively. Project resource management involves much more than using software to assess and track resource loading and to level resources. People are the most important asset on most projects, and human resources are very different from other resources. You cannot simply replace people in the same way that you replace a piece of equipment. It is essential to treat people with consideration and respect, to understand what motivates them, and to communicate carefully with them. What makes good project managers great is not their use of tools, but their ability to enable project team members to deliver their best work on a project. C A S E WR A P - U P Case Study: After Sarah yelled back at Ben, he said, You re the first person who s had the guts to stand up to me. After that brief introduction, Sarah, Ben, and the other meeting participants had a good discussion about what was happening on the F-44 upgrade project. Sarah was able to write a justification to get Ben s group special software and support to download key information from the old system so they could manage their project better. When Sarah stood nose to nose with Ben and yelled at him, she used a technique for establishing rapport called mirroring. Although Sarah was not a loud and obnoxious person, she saw that Ben was and decided to mirror his behavior and attitude. She put herself in his shoes for a while, which helped break the ice so Sarah, Ben, and the other people at the meeting could start communicating and working together as a team to solve their problems. 188

189 10.8 SUMMARY In this unit, you have learnt the importance of staff acquisition and the tools and techniques used for staff acquisition. The output of staff acquistion have been discussed in detail. The case study involved in team development and staff acquisition has been discussed. The issues to be considered in Team development and Project staff acquisition have been discussed in detail. The usage of software in staff acquisition has also been discussed here KEYWORDS Negotiation, Procurement, Cohesiveness UNIT END EXERCISE 1. What is Staff Acquisition? Explain the tools and techniques for staff acquisition and its output 2. Consider Case study to explain the Staff acquisition 3. What is Team development? Explain the 5 issues considered in Project staff acquisition and team development. 4. What is the role of using software in Human Resource Management? Explain SUGGESTED READING 1. Information Technology Project Management Kathy Schwalbe, International Student Edition, THOMSON CourseTechnology, Software Project Management Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill 3. Microsoft Office Project 2003 Bible, Elaine Marmel, Wiley Publishing Inc. 189

190 UNIT 11: PLANNING AND REPORTING Structure: 11.0 Objectives 11.1 Communication Planning 11.2 Information Distribution 11.3 Performance Reporting 11.4 Administrative Closure 11.5 Summary 11.6 Keywords 11.7 Unit-end exercises and answers 11.8 Suggested readings 11.0 OBJECTIVES At the end of this unit you will be able to know: Understand the communication planning Explain how the information is distributed Sketch the performance reporting of staff Understand the administrative closure 11.1 COMMUNICATION PLANNING Communication planning is the art and science of reaching target audiences using marketing communication channels such as advertising, public relations, experiences or direct mail for example. It is concerned with deciding who to target, when, with what message and how. 190

191 In 'The Better Mousetrap: Brand Invention in a Media Democracy, Pont emphasises that Communications planning takes the consumer as the start point, rather than the brand, and acknowledges that people don t experience brand messages in neatly wrapped and singular packages. People build an overall and ever shifting impression of a brand through a non-linear set of messages, whether that brand exposure is a million-dollar TV ad, a beer coaster, bumper sticker, or an editorial piece they read on the train. It is channel agnostic, and thus argues that brand communications is the sum total of all points of contact with consumers, how they join up, interplay and write themselves large and compelling, adding (with hope) to a significantly greater whole. In execution, the communication plan serves as a guide to the communication and sponsorship efforts throughout the duration of the project. It is a living and working document and is updated periodically as audience needs change. It explains how to convey the right message, from the right communicator, to the right audience, through the right channel, at the right time. It addresses the six basic elements of communications: communicator, message, communication channel, feedback mechanism, receiver/audience, and time frame. A communication plan includes: Who - the target audiences What the key messages that are trying to be articulated When timing, it will specify the appropriate time of delivery for each message Why the desired outcomes How - the communication vehicle (how the message will be delivered) By whom - the sender (determining who will deliver the information and how he or she is chosen) Many agencies, PR, advertising and media alike, claim to have this capability Communications Planning - What Is It? People and organizations communicate with others for a variety of reasons - to inform, persuade, prevent misunderstandings, present a point of view or reduce barriers. 191

192 Communications happens when the message you send is received, understood and acted upon by your intended audience. Communications planning is simply a process to help you reach that goal. The communications plan has been described in a number of ways, including: A foundation on which to base decisions and create ideas A means of focusing on where you want to be and what needs to be done to get there A tool for discovering opportunities, optimizing challenges and initiating change, and A means of monitoring your communications efforts. A communications plan is all of the above... and more. But communications planning is not a mysterious art. It is a straightforward, step-by-step process that will help you clearly and logically summarize what you want to say to your intended audience and map out how you will deliver that message. Keep in mind, the same logical process used to launch a new consumer product on a national basis can also be used to inform parents about a bake sale to raise funds for their child's school trip Why Communicate? Organizations need to communicate for one or all of the following reasons: To inform You may need to let interested parties know who you are, what you can do for them, what they can do to help you, or even just how to get in touch. To build understanding or change behaviour You may want to encourage others to think, act or feel a certain way; to stop smoking, for example. This can involve appealing to feelings, self-interest, or a person's imagination. To prevent misunderstandings Even a small misunderstanding can create large problems for your organization. You can ensure good communication by putting yourself in your audience's position, paying attention to their needs and getting to know them. To present a point of view Often, this is all you need to do to accomplish your goal. 192

193 To lower barriers between groups and individuals These barriers may range from information overload to suspicion and prejudice Communications Planning - The Six Steps Step 1 - Research and Analysis or Take Stock of Your Current Situation Start your communications planning with some research. Research can be as extensive as commissioning a public opinion poll or as simple as talking on an informal basis with your clients or staff. It also means asking the following questions about your current situation and what affects it: What are your organization's goals, strengths and weaknesses? Having a clear picture of what your organization wants to achieve will help you determine a good course of action for your communications. What resources do you already have? Information, people, money, time and public support are all valuable assets. Determining which assets you have and which ones you might need will help you decide on the scope of your communications program. Is there any current research that will help you? Do you need to do any research? Has this type of communications activity taken place before? If so, what was the result? What are your major communications opportunities? Perhaps the local newspaper is always interested in your organization's activities. Or maybe there's an annual meeting coming up where you can present your messages. What are your major communications impediments? Perhaps you don't have a lot of money to spend on communications so you will need to look for low-cost opportunities. The analysis stage involves sifting through the research to look for information that will help you frame your communications plan. Analysis can help you: Define your communications challenge Identify friends (and opposition) and suggest their motivation Help identify audiences, place them in order of importance and determine how they perceive your organization, and Suggest what messages should be directed to your audience. 193

194 Step Two - Goals and Objectives Defining your goals and objectives or what you are trying to achieve will help you focus on the who, why, when and how of your communications planning. Goals are the overall changes you wish to cause. Objectives are the short-term, measurable steps you take to reach your goal. For Example: If your goal is to increase community support for your local community development initiative, your objectives might be to: increase your membership by 10% add two new organization directors increase funding from the business community encourage positive media coverage of your organization's activities inform the community of the benefits of community development, and Achieve support for your activities from local civic leaders. When deciding on your objectives, ask yourself: Are we seeking to provide new information? Are we calling the audience to action? Are we seeking to change behaviour? Your objectives should form a clear statement of what it is you are trying to do. They should be specific, realistic and listed in order of importance. They should also be measurable. When you evaluate your communications plan, you will measure your results against your objectives. Step Three - Target Audience The next step in the planning process is to determine your target audiences by: listing the groups with whom you need to communicate, and Analyzing each group. When choosing the people or groups your organization needs to influence, it may be helpful to think about the many different ways you can describe them. For example, your target audience might be males aged 18 to 212. But, it could be more helpful to know that your target audience is males aged 18 to 24 who are car owners or football players or volunteer fire fighters or teachers. 194

195 The more clearly you can define your audience, the easier it will be to make choices about your messages and communications vehicles. When analyzing each group, consider: What do they already know about your organization? How are they likely to react to your message and why? What are some factors influencing the audience that receives your message - for example: literacy levels or multicultural differences? Are there any difficulties you might have in communicating with each group? Possible Target Audiences Business People Industrial and commercial business owners Officials of merchants' associations Employment agency management Contractors and construction company officials Union leaders Professional People Clergy Doctors Dentists Pharmacists Veterinarians Lawyers Bankers Professional engineers Educators Members of school boards School superintendents Principals Teachers 195

196 Step Four - Key Messages Taking into consideration your objectives and target audiences, it is now time to identify the essential idea or set of ideas you want to communicate. Ask yourself - What does the audience already know about this issue? What does the audience need to know? What do we want to tell the audience? Now, develop the message or messages you want your target audience to hear and to believe. Write down each message in a simple, specific statement. Keep in mind, to motivate people, you must show them that you will help meet their needs. A clear description of the benefits to your audiences will help ensure that your message is received, understood and acted upon. Step 5 - Communication Strategy Tactics There are many communications vehicles available from which to choose. A number of them are listed on the last page of this Factsheet. Having done your communications analysis, you will be able to narrow your choices to the communications vehicles that: Fit with the resources you already have Are the most effective communications vehicles to reach your target audiences and influence them with your message(s), and Help you achieve your goals and deliver the outcomes you want. Timing is another very important consideration when choosing your communications vehicles. You don't want your messages competing unnecessarily with other events. Finally, there is the budget. Don't let a limited budget discourage you. There are many inexpensive communication vehicles. Your communications plan may need a theme to tie it together. The theme line should be a short, punchy version of your main message and should be the link between all your activities and materials. Foodland Ontario's There's No Taste Like Home slogan is a good example of capturing a message (that Ontarians should buy Ontario-grown food) in one catchy phrase. 196

197 Implementation Make a list of all the activities that will take place: Before the launch of your communications campaign; for example, preparing a mailing list, writing a news release At the time of the launch; for example, distribution of the news release, and As a follow-up; for example, responding to media inquiries resulting from the news release. If you develop a long-term plan, be sure to build in some check points to monitor progress and aid adjustments. Step Six - Evaluation How will you know if you are successful? Will the audiences receive the messages you intend them to receive, or will they get an entirely different message? By evaluating your communications plan, you can learn how your plan worked with various audiences, which activities had the most impact, and which parts of the plan failed. There are a variety of formal measurement techniques for measuring the results against your objectives, such as: readership surveys, attitude audits, focus group sessions. You can do your own evaluation on a less formal basis by assessing media coverage and talking to your clients. The evaluation of your first plan should form the foundation of your next communications plan. Organization/Corporate Communications Spokesperson Speeches Special events Displays Trade shows or special client-group meetings Annual and other reports Annual meetings 197

198 11.2 INFORMATION DISTRIBUTION Project management demands a free flow of communication with and among project team members, and internal and external project stakeholders. The project team needs frequent information from each of its team members to complete and improve the project and to understand the needs and expectations of the project's beneficiaries. Project Communication management is the systematic planning, implementing, monitoring, and revision of the exchange of information amongst the project team and the project stakeholders. Project communication management aims at timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information and knowledge. Communication among all project stakeholders is one of the main factors for the project success. It is a prerequisite of getting the things done in the right way and in the right time. Knowledge is power: sharing knowledge is reciprocal empowering amongst project stakeholders. A good Project Plan has, in the methodology section, a sub-section dealing with communication management. A good project implementation plan always contains a communication plan; in any case it is important to plan communication at an early phase of project execution. The communication plan describes how the information and communication needs of project stakeholders will be met: a communication manager will design, and implement such a plan; thereafter s/he will evaluate how efficient and efficacious communication has been as a support activity facilitating all other project tasks. Never underestimate communication in project management. Communicate well, and the project will succeed. Communicate poorly, and even the most efficient efforts may be misperceived, misunderstood and poorly valued. In the the project execution phase, communication management is the implementation of the plan and involves essentially two processes: preparing (producing) and sharing (distributing) information. While executing the plan, the Project Manager must be aware of how the organization will use the information, and whether the plan is effective. He/she must be flexible and ready to modify the plan if portions of it are not working as expected or communications needs change within the Performing Organization. Of the many mechanisms available to the Project Manager, status reporting is particularly useful for communicating the performance of a project. In order to prepare and distribute properly the right information to the right stakeholders, the communication manager needs to: Analyse the communication needs of each stakeholders 198

199 Identify the information for fulfilling the information needs of each stakeholder Identify the Method and the Effort Required Prioritise the Communication Options Information Distribution includes Project performance reporting, but is not limited to that: it entails also all tasks required to satisfy the information needs of all project stakeholders. Types of Project Communication Internal communicating within the project team External communication with upper management, beneficiaries, and external players Close-out reporting As a project progresses, events may occur to alter the way information is accessed or change communications requirements. During Project Execution, the Project Manager and Project Team must again review whether the Communications plan is still current and applicable to the present phase of the project. In addition to having a solid Communications Plan in place, it is the responsibility of members of the Project Team to exercise good communication skill. Communication skill is critical to keeping your stakeholders informed, supportive. Smart planning and consistent information delivery keeps your project on track and helps avoid confusion. When composing correspondence, progress reports, meeting minutes, etc., and when speaking with individuals face to face, the team members are responsible for clear, unambiguous, and complete communication of information. The receiver, in turn, must be sure information is not only received correctly and completely, but that it is understood. During Project Execution, the Project Manager, Project Team, and Stakeholders will share information using a variety of communication mechanisms. See Tasks, tools and elements of communication management In the structure of the project, communication management is considered one of the facilitating processes (along with quality planning, staff acquisition, risk response planning, procurement planning, solicitation planning). "Facilitating" does not mean unessential or optional: it only means that it is a process that varies in the sequence, is performed in parallel with other activities, have a two-way feedback loop with many core processes. (core processes of project management instead are performed sequentially and are divided into three main phases, i.e. project planning, project execution, project closure). 199

200 Reporting project status While executing the plan, the Project Manager must be aware of how the organization will use the information, and whether the plan is effective. HS/he must be flexible and ready to modify the plan if portions of it are not working as expected or communications needs change within the Performing Organization. Of the many mechanisms available to the Project Manager, Status reporting is particularly useful for communicating the performance of a project. During the meeting the Project Manager should review the Project Schedule with the team and verify with each member the work that needs to be accomplished in upcoming weeks. Part of the meeting should focus on the team s Progress Reports, to verify estimates to complete tasks and to discuss issues that may impact estimates. The Project Manager can then use information communicated during the Project Team meetings as input to the Status Report. The regularly-scheduled Project Team meeting is also a good forum to recognize individual accomplishments, and to reward team members for outstanding work. As a project progresses, events may occur to alter the way information is accessed or change communications requirements. During Project Execution, the Project Manager and Project Team must again review whether the Communications plan is still current and applicable to the present phase of the project PERFORMANCE REPORTING The definition of Performance Report is Performance reports organize and summarize the information gathered, and present the results of any analysis as compared to performance measured baselines. In other words, the Performance Report organizes, and summarizes the information collected during the Work Performance Information, and Work Performance Measurement. Then it represent to stakeholders in such a way that they can understand the direction the project is going. From the Performance Report, stakeholders can see the project performance, and current status. If the project is not going as it was planned then stakeholders may decide for any corrective action such as if any extra fund, resource, or time extension should be given to complete the project. The format and type of Performance Reports are dependent on the stakeholders needs and requirements and whether they want a detailed report, or just a summary. 200

201 Performance Reports may be any type of combination of these formats: Burn down Chart S-Curve Bar Charts Histograms Tables Run Charts. The content of the Performance Report includes, but is not limited to: Percentage of the work completed during the reporting period Balance of work to be completed Cost incurred during the reporting period Balance of funds available Balance of time available Major risks that have occurred, or passed without occurring Major remaining identified risks Results of variance analysis; e.g. schedule variance (SV), and cost variance (CV) Performance indexes; e.g. schedule performance index (SPI), and cost performance index (CPI) Forecasted fund required to complete the balance work (if project cost is over run, or under run) Forecasted time required to complete the balance work (if project is delayed, or ahead of schedule) Summary of major approved change requests during the reporting period etc. Keep in mind that WPI is a collection of raw information of the project s status. WPM is a comparison of various performances like cost and schedule etc. The Performance Report is the Report that is to be given to project stakeholders to make them aware of the current status of the project. The Performance Report shows stakeholders how the project is going, the forecast analysis of what they should expect if the project is allowed to keep going in the same way, or 201

202 what additional funds or resources may be required to complete the project if there is any deviation from any baselines. Process Input Work Performance Information Performance Measurements Forecasted Completion Quality Control Measurements Project Management Plan Approved change requests Deliverables Process Definition Performance Reporting is the process for collection and distributing performance information like status reporting, progress measurement, and forecasting: On the base of the collected performance information concerning scope, schedule, cost and quality this process generates the reports which are distributed to the stakeholders. Basically one can determine four types of reports: Forecast reports for describing future trends Progress reports for describing trends from past to presence Status reports for describing actual status Variance reports for describing differences between the planned baseline and the real data Part of the Monitoring and Controlling Process Group Child Process of Monitor and Control Project Work Direct and Manage Project Execution Member of Knowledge Area Project Communications Management The subject Communications Management operates on the base of other communications concerning concepts. 202

203 Tools and Techniques Information presentation tools today are mostly software packages that include table reporting, spreadsheet analysis, presentations, or graphic capabilities Performance information gathering and compilation is mostly supported by electronic media or software Status review meetings are regularly scheduled events to exchange information. Projects can have multiple status review meetings at various frequencies and on different levels Time reporting systems record and provide time expended for the project. Format, content, and context will be set by the time management processes Cost reporting systems record a provide cost expended for the project. Format, context, and context will be set by the time management processes. Process Output Performance Reports organize and summarize the information gathered, and present the results of any analysis ad compared to the performance measurement baseline. One of the methods to aggregate and connect different information is the earned value technique: In this context it combines the scope of the WBS with schedule baseline, the really reached work and the costs of the cost baseline. Forecasts are generated by extrapolating the really observed performance into the future Requested changes can be evoked by the performance analysis and are processed and dispositioned through the Integrated Change Control process Recommended Corrective Actions include changes that bring the expected future performance of the project in line with the project management plan Updates of the Organizational Process Assests are evoked by lessons learned concerning the performance itself and the performance reporting as method Output Using Successor Processes Integrated Change Control Scope Control Schedule Control 203

204 Cost Control Manage Project Team Risk Monitoring and Control Contract Administration 11.4 ADMINISTRATIVE CLOSURE Administrative closure involves bringing to completion all internal aspects of the project concerning team members, management, other stakeholders, financials and equipments. The following processes ensure that no loose ends are left dangling: Deliverable Turnover-Verification and Acceptance: In this step, deliverables are reviewed and tested against previously determined requirements and are accepted by the customer with a formal sign-off. Post completion Data: In this step, you determine any variances in the schedule, cost, and scope. Follow-up Maintenance and Warranties: If applicable, hand off any hardware, software, or other equipment and review the coverage on warranties and the maintenance requirements. Team Member Performance Reporting: The project manager provides information to functional management on the performance of project team members during the life of the project. Financials: Ensure that all expenses are paid and project budgets are closed. Generate the necessary financial reports. Releasing Staff: Ensure a smooth transition for all staff to new assignments. Notify functional managers with sufficient lead time so that meaningful work assignments can be made. Formal Closing Report: Prepare a summary of the information above, including any open issues, and distribute it to appropriate stakeholders. 204

205 Contract Closure: A contract is closed upon reaching the end of the contract, or when a contract is terminated before his work is completed (usually by the buyer if the work is no longer required, or if the work performed is not acceptable due to quality or other reasons). The seller may still need to be compensated for the work completed, as governed by the clauses in the contract. In multi-phase projects, Close Procurements closes the appropriate contract(s) for that phase of the project. Thus, the Close Procurements process may be repeated many times in a project. Unresolved claims may be subject to litigation after Close Procurements is completed. A complete set of indexed contract documentation, including the closed contract, is prepared for inclusion in the final project files Output of Close Procurements. Key Difference between Administrative and Contract Closure: Procurement Closure or Contract Closure is done before the project can be closed completely. Procurement Closure may be done multiple times (once for each contract) during the lifecycle of a project. Administrative Closure is only done once per phase, or for the entire project. Project closure is not complete without procurement closure. Product acceptance is carried out using the Close Project or Phase process. The contracts are closed using the Close Procurement process SUMMARY In this unit, you have learnt the importance of planning the communication in different department in project. Knowledge about how Information is distributed among the department is discussed in detail. The Performance reporting from the start of the project till the end is also discussed. Administrative closure which involves bringing to completion all internal aspects of the project concerning team members, management, other stakeholders, financials and equipment s is also been discussed. 205

206 11.6 KEYWORDS Target Audience, Clergy, Project stakeholders, Close out reporting, Turn-over verification, Contract closure 11.7 UNIT END EXERCISE 1. What is Communication planning? Explain 2. Explain Information Distribution in detail. 3. What is Performance Reporting? Explain 4. Explain the Administrative Closure function in detail 11.8 SUGGESTED READING 1. Information Technology Project Management Kathy Schwalbe, International Student Edition, THOMSON CourseTechnology, Software Project Management Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill 3. Microsoft Office Project 2003 Bible, Elaine Marmel, Wiley Publishing Inc. 206

207 UNIT 12: PROJECT COMMUNICATION Structure: 12.0 Objectives 12.1 Project Communication 12.2 Suggestions for improving project communication 12.3 Developing better communication skills 12.4 Using software to assist in Project Communication 12.5 Summary 12.6 Keywords 12.7 Unit-end exercises and answers 12.8 Suggested readings 12.0 OBJECTIVES Communication and leadership go hand in hand. Communication is NOT ONLY talking to the troops, and telling them what you expect of them - it goes much deeper. Successful project communication is about being there for everyone, being in touch with the real challenges of the project, understanding the real issues within the team who must deliver the project as well as understanding the issues of the sponsors who the team delivers the project for. Being present, visible and engaged with everyone is IMPORTANT - during the good times and the challenging times PROJECT COMMUNICATION The number one reason to plan your project communications is to help your projects succeed. Project communications is more than meetings and memos. Planned project communications: Provide open and two-way information flows. 207

208 Facilitate problem identification and resolution. Ensure effective decision-making. Involve key stakeholders throughout the project and facilitate teamwork. Project Communication Plan? A project communication plan is a written strategy for getting the right information to the right people at the right time. A typical project communication plan has the following basic components: Communications purpose the goals and objectives of the project communication process Communications methods the mechanisms and formats for the varying elements of the project communication process Communications frequency the timing and frequency requirements for all formal and informal communication activities Expert s opinion about Project Communications According to the Project Management Institute (PMI ) and the Project Management Book of Knowledge Guide (PMBOK ), project communications is a key knowledge area with processes that provide the critical links among people and information that are necessary for successful communications. Communication ranks high in the list of causes for project failures. In fact, according to the 1998 Bull Survey, the leading cause (57%) of project failures was "bad communications between relevant parties." Gannthead.com, a key resource for project managers, states that in today s world, communications management is fundamental to project management in managing expectations. Since change is constant in an agile project, constant communication is the only means of maintaining the connections between all the participants. 208

209 Steps to Planning Project Communications Once you have determined the goals for your project communications, you can follow four simple steps to develop your plan. You can expand each of these steps to support the level of complexity of each project. Step 1: Identify your project stakeholders - anyone who is involved in the project, affected by the project, or affected by the outcome of the project. Step 2: Analyze the needs and expectations of your stakeholders. Step 3: Identify existing and possible new communications vehicles or opportunities and choose the appropriate vehicles for your stakeholders. Step 4: Develop, document, and monitor your communications plan. Communications Goals? Communication goals convey what we are trying to accomplish from an information standpoint. Explicitly stating these goals helps to focus your project communication efforts. Following are some typical project communications goals: To ensure that all essential information gets to the required parties at the right time, quickly and efficiently. To identify and raise potential problems via scheduled, consistent status reporting. To generate excitement and enthusiasm for a project. To facilitate decision-making, approvals and change control. To provide a specific process for feedback and conflict resolution. To ensure appropriate transition upon project closure. To enhance and facilitate teamwork, cooperation, and collaboration. Planning Communication The communications management plan varies with the needs of the project, but some type of written plan should always be prepared. The communications management plan can be part of the team contract. 209

210 For large projects, it should be a separate document. The communications management plan should address the following items: 1. Stakeholder communications requirements 2. Information to be communicated, including format, content, and level of detail 3. Who will receive the information and who will produce it 4. Suggested methods or technologies for conveying the information 5. Frequency of communication 6. Escalation procedures for resolving issues 7. Revision procedures for updating the communications management plan 8. A glossary of common terminology It is important to know what kinds of information will be distributed to particular stakeholders. By analyzing stakeholder communication needs, you can avoid wasting time or money on creating or disseminating unnecessary information. MANAGING COMMUNICATIONS Managing communications is a large part of a project manager s job. Getting project information to the right people at the right time and in a useful format is just as important as developing the information in the first place. The stakeholder communications analysis serves as a good starting point for managing communications. Project managers and their teams must decide who receives particular information, but they must also determine the best way to create and distribute the information. Is it sufficient to send written reports for project information? Is text appropriate, or would visuals or even videos communicate the information better? Are meetings alone effective in distributing some project information? Are meetings and written communications both required for project information? What is the best way to provide information to virtual team members? During project execution, project teams must address important considerations for managing information, and they often end up updating business processes through improved communications. Some of the effective managing communication is mentioned below: Using Technology to Enhance Information Creation and Distribution Selecting the Appropriate Communication Methods and Media Reporting Performance 210

211 CONTROLLING COMMUNICATIONS The main goal of controlling communications is to ensure the optimal flow of information throughout the entire project life cycle. The main inputs are the project management plan, project communications, issue logs, work performance data, and organizational process assets. The project manager and project team should use their various reporting systems, expert judgment, and meetings to assess how well communications are working. If problems exist, the project manager and team need to take action, which often requires changes to the earlier processes of planning and managing project communications. The main outputs of controlling communications are work performance information, change requests, project documents updates, and organizational process assets updates. It is often beneficial to have a facilitator from outside the project team assess how well communications are working. A facilitator can also help the team solve any communication problems. Many project teams need help in improving communications, and many internal and external experts are available to help. The following section also provides suggestions for improving project communications SUGGESTIONS FOR IMPROVING PROJECT COMMUNICATIONS No matter how much hard work you do in your project you are bound to run into some problems if the communication isn t right. Project communication covers quite a few different concepts so it is worth making this something you focus on. Make It a Priority The biggest risk of failure in your communication strategy is probably going to come from not having one in the first place. If you make a conscious effort to think about this on an ongoing basis then it is far more likely to be more successful. On the other hand, if you don t show a lot of interest in the communication you send out then you are always going to find something more important to occupy your time. You might want to assign someone to work exclusively on this aspect of the project or you might want to do it yourself. The most important thing is that you give this the priority level it deserves. 211

212 Don t Assume You Know Everything One of the things I like best about the project world is that you learn something just about every day. Just as you think that you are an expert in the subject you are dealing with, an issue will crop up which leaves you stumped. This means that you need to always be aware that asking someone else for help or advice is an option. This of course means that your communication with stakeholders and team members has to be a two way affair. If you simply tell them what you know then you won t give them the chance to add their knowledge to the project. Make It Positive Where Possible No one wants to hear bad news all the time, and least of all stakeholders who are already getting nervous about meeting deadlines and budgets. I am not suggesting here that you feed them lies or spin but you should be careful about the way you word things which could be taken as being negative. I look at it this way; if I control the project then I know where it is going and whether something is under my control or not. If we have 500 processes to check in a week then I won t just write this down on a project update, as the bald figures might look really bad to a stakeholder who doesn t know everything that I do. I will analyze the figures and work out how to achieve what needs done. The communication will then explain what needs done and how it will be done. Use Different Channels Sending out a weekly is fine but you will also want to give updates in person or over the phone from time to time as well. When you are communicating with project team members you have also the choice of taking them away for a project update day or simply sending out a quick . If people get fed information in the same way every time I find that they can end up not paying as much attention to the details as they might otherwise do. You can freshen things up and grab their attention by using different tools such as pie charts, graphs and pictures to get your message across in an interesting sort of way. 212

213 Keep It Up to Date and Concise The best chance you have of getting people to pay attention to your communication is if you make sure that it is all current information which is new to them. Obviously you aren t going to rush to your PC to send out an or call a meeting every time that something important happens. However, you should keep a note of the major events during the week in order to include them in whatever type of communication method is due to be used next. You certainly don t want your stakeholders or team members finding out about a vital issue from third parties long after the time in which you should have mentioned it. In the same way, you don t want to miss out on any sort of information which could be of interest to you, so you need to keep your inward communication channels open. The final bit of advice is to keep your updates concise. You will only bore people into stopping reading if you go into a lot of unnecessary details. Most of the people you communicate with don t really need to know all the ins and outs of what is going on in relatively minor tasks DEVELOPING BETTER COMMUNICATION SKILLS Some people seem to be born with great communication skills. Others seem to have a knack for picking up technical skills. It is rare to find someone with a natural ability for both. Both types of skills, however, can be developed. Most IT professionals enter the field because of their technical skills. Most find, however, that communication skills are the key to advancing in their careers, especially if they want to become good project managers. As organizations become more global, they realize that they must also invest in ways to improve communication with people from different countries and cultures. For example, many Americans are raised to speak their minds, while in some other cultures people are offended by outspokenness. Not understanding how to communicate effectively with people of other cultures and diverse backgrounds hurts projects and businesses. Many training courses are available to educate people in cultural awareness, international business, and international team building. Workers also need to learn how to participate in virtual meetings and conference calls. Some people take these skills for granted, but many people need assistance in becoming comfortable and productive in new work environments. 213

214 It takes leadership to help improve communication. If top management lets employees give poor presentations, write sloppy reports, offend people from different cultures, or behave poorly at meetings, the employees will not want to improve their communication skills. Top management must set high expectations and lead by example. Running Effective Meetings A well-run meeting can be a vehicle for fostering team building and reinforcing expectations, roles, relationships, and commitment to the project. However, a poorly run meeting can have a detrimental effect on a project. For example, a terrible kick-off meeting may cause important stakeholders to decide not to support the project further. Many people complain about the time they waste in unnecessary or poorly planned and poorly executed meetings. The following guidelines can help improve time spent at meetings: Determine if a meeting can be avoided. Do not have a meeting if there is a better way of achieving the objective at hand. For example, a project manager might need approval from a top manager to hire another person for the project team. It could take a week or longer to schedule even a 10-minute meeting on the top manager s calendar. Instead, an or phone call describing the situation and justifying the request is a faster, more effective approach than having a meeting. However, you often do need a face-to-face meeting in certain situations because using or a phone call would be inappropriate. Consider which medium would be most effective. Define the purpose and intended outcome of the meeting. Be specific about what should happen as a result of the meeting. Is the purpose to brainstorm ideas, provide status information, or solve a problem? Make the purpose of a meeting very clear to all meeting planners and participants. For example, if a project manager calls a meeting of all project team members without knowing the true purpose of the meeting, everyone will focus on their own agendas and very little will be accomplished. All meetings should have a purpose and intended outcome. Determine who should attend the meeting. Do certain stakeholders have to be at a meeting to make it effective? Should only the project team leaders attend a meeting, or should the entire project team be involved? Many meetings are most effective with the minimum number of participants possible, especially if decisions must be made. Other 214

215 meetings require many attendees. It is important to determine who should attend a meeting based on its purpose and intended outcome. Provide an agenda to participants before the meeting. Meetings are most effective when the participants come prepared. Did they read reports before the meeting? Did they collect necessary information? Some professionals refuse to attend meetings if they do not have an agenda ahead of time. Insisting on an agenda forces meeting organizers to plan the meeting and gives potential participants the chance to decide whether they need to attend. Prepare handouts and visual aids, and make logistical arrangements ahead of time. By creating handouts and visual aids, you must organize thoughts and ideas. This usually helps the entire meeting run more effectively. It is also important to make logistical arrangements by booking an appropriate room, having necessary equipment available, and providing refreshments or entire meals, if appropriate. It takes time to plan for effective meetings. Project managers and their team members must take time to prepare for meetings, especially important ones with key stakeholders. Run the meeting professionally. Introduce people, restate the purpose of the meeting, and state any ground rules that attendees should follow. Have someone facilitate the meeting to make sure that important items are discussed, watch the time, encourage participation, summarize key issues, and clarify decisions and action items. Designate someone to take minutes and then send them to all participants soon after the meeting. Minutes should be short and focus on the crucial decisions and action items from the meeting. Set the ground rules for the meeting. State up front how the meeting will be run. For example, can people speak at will, or will the facilitator lead discussions? Can attendees use their laptops or other electronic devices during the meeting? Don t assume that all meetings are run in the same way. Do what works best in each specific case. Build relationships. Depending on the culture of the organization and project, it may help to build relationships by making meetings fun experiences. For example, it may be appropriate to use humor, refreshments, or prizes for good ideas to keep meeting participants actively involved. If used effectively, meetings are a good way to build relationships. 215

216 Using , Instant Messaging, Texting, and Collaborative Tools Effectively The following guidelines can help you use several communication tools more effectively: Information sent via , instant messaging, texting, or a collaborative tool should be appropriate for that medium. If you can communicate the information better with a phone call or meeting, for example, then do so. Be sure to send the , text, or instant message to the right people. Do not automatically reply to all on an , for example, if it is not necessary. Use meaningful subject lines in s so readers can quickly see what information the message contains. If the entire message can fit in the subject line, put it there. For example, if a meeting is cancelled, just enter that message in the subject line. Also, do not continue replying to messages without changing the subject line. The subject should always relate to the latest correspondence. Limit the content of the to one main subject. Send a second or third if it relates to a different subject. The body of the should be as clear and concise as possible, and you should always reread your before you send it. Also, be sure to check your spelling using the spell-check function. If you have three questions that you need answered, number them as questions 1, 2, and 11. Limit the number and size of attachments. If you can include a link to an online version of a document instead of attaching a file, do so. Delete that you do not need to save or that does not require a response. Do not even open that you know is not important, such as spam. Use the blocking feature of the software, if available, to block unwanted junk mail. Make sure that your virus protection software is up to date. Never open attachments if you do not trust the source. Respond to quickly, if possible. It will take you longer to open and read the again later. In addition, if you send an that does not require a response, make that clear as well. If you need to keep , file each message appropriately. Create folders with meaningful names to file the messages you want to keep. File them as soon as possible. 216

217 Learn how to use important features of your , texting, instant messaging, and collaborative software. Using Templates for Project Communications Many intelligent people have a hard time writing a performance report or preparing a 10- minute technical presentation for a customer review. Some people in these situations are too embarrassed to ask for help. To make it easier to prepare project communications, project managers need to provide examples and templates for common project communications such as project descriptions, project charters, monthly performance reports, and issue logs. Good documentation from past projects can be an ample source of examples. Samples and templates of both written and oral reports are particularly helpful for people who have never had to write project documents or give project presentations. Finding, developing, and sharing relevant templates and sample documents are important tasks for many project managers. Several examples of project documentation are provided throughout this text, including a business case, project charter, scope statement, stakeholder analysis, WBS, Gantt chart, and cost estimate. The companion Web site for this text includes the actual files used to create the templates for these sample documents. Case Study: Communications technology, such as and the Web, should help improve project communications, but it can also cause conflict. How? Most people have heard the term slackers before, referring to people who avoid work. But have you heard of cyberslackers? Cyberslackers are people who should be working, but instead spend company time online on activities that are not related to work, such as annoying friends or coworkers by sending unimportant s. A study by Websense found that employees are using the Web more and more for personal reasons, and that it costs U.S. companies $178 billion annually, or $5,000 per employee. Websense determined this number by surveying managers, who estimated that each employee was cyberslacking for 5.9 hours a week on average, and then multiplying the number by the average American hourly salary. Cyberslacking is not a new phenomenon, nor is it restricted to people in certain countries. In 2000, Internet Security Company Surf control estimated that every employee in Australia was taking the equivalent of a two-week cyberholiday each year, costing the nation $210.5 billion annually. A two-year research project by postgraduate psychology student Kerryann Wyatt found that cyberslacking could account for as 217

218 much as a quarter of the time employees spend online, and even more if they have outgoing personalities. Of the many Internet distractions, ing friends was the most popular, followed by general Internet searches, according to Wyatt s research. One of the goals of the study was to match personality types with Internet misuse at work. Wyatt said her findings indicated that, contrary to previous studies, introverted participants were not the key offenders. The report said: People scoring highly in extroversion were significantly more likely to send higher numbers of both work and non work-related s. A 2008 survey found that more than a quarter of U.S. employers have fired workers for misusing and that one-third has fired workers for misusing the Internet on the job. Of the managers surveyed, 84 percent said employees were fired for accessing pornography or other inappropriate content on the Internet. Among managers who fired workers for misuse, 64 percent did so because the employee violated company policy, and 62 percent said the contained inappropriate or offensive language. Most employees who were fired knew that their computer usage was being monitored USING SOFTWARE TO ASSIST IN PROJECT COMMUNICATIONS Many organizations are discovering how valuable project management software can be in communicating project information across the organization. Project management software can provide different views of information to help meet various communication needs. For example, senior managers might only need to see summary screens with colors indicating the overall health of all projects. Middle managers often want to see the status of milestones for all of the projects in their area. Project team members often need to see all project documentation. Often, one of the biggest communication problems on projects is providing the most recent project plans, Gantt charts, specifications, meeting information, and change requests to stakeholders in a timely fashion. Most project management software allows users to insert hyperlinks to other project-related files. In Project 2010, you can insert a hyperlink from a task or milestone listed in a Gantt chart to another file that contains relevant information. For example, there might be a milestone that the project charter was signed. You can insert a hyperlink to the Word file that contains the project charter from the Gantt chart. You could also link appropriate tasks or milestones to Excel files that contain a staffing management plan or cost estimate or to Microsoft PowerPoint files with important presentations or other information. The Project 2010 file and all 218

219 associated hyperlinked files could then be placed on a local area network server or Web server, allowing all project stakeholders easy access to important project information. Even though organizations routinely use many types of hardware and software to enhance communications, they need to take advantage of new technologies and adjust existing systems to serve the special communications needs of customers and project teams. In addition to diverse customer and project needs, they have to address the changing expectations of consumers and the workforce. For example, several television shows have harnessed communications technology to engage their audiences by letting them vote online or via cell phone for their favorite singers, e- mail or tweet celebrities, or access information on their Web sites or Facebook pages. Many people, especially younger people, use instant messaging or text messages every day to communicate with friends. Some business and technical professionals also find instant messaging and text messaging to be useful tools for quickly communicating with colleagues, customers, suppliers, and others. Web logs, or blogs, are journals on the Web that allow users to write entries, respond to another poster s comments, create links, upload pictures, and post comments to journal entries. Blogs have also become popular as a communication technology. If television shows and nontechnical people can use advanced communications technologies, why can t project stakeholders? Employers have made changes to meet changing expectations and needs in communications. The Telework Coalition reports that since 1990, the number of people telecommuting has grown from about 4 million to more than 45 million. At IBM, 40 percent of its 330,000 employees work from home, on the road, or at a client location on any given day. TechCast at George Washington University forecasts that by 2019, 30 percent of U.S. privatesector workers could work from home. Gartner predicts that this drive to mobility will become a $1 trillion market in the next four years... within this decade, most, if not all workers will be mobile to some degree. On several IT projects, project managers have found that their team members can be more productive when they are allowed to work from home. Other project managers have no choice in the matter when some or all of their project team members work remotely. Studies show that providing a quiet work environment and a dedicated workspace increases programmer productivity. Most people who work from home have well-equipped, comfortable offices with fewer distractions and more space than corporate offices. Workers also appreciate the added bonus of avoiding traffic and having more flexible work schedules. 219

220 However, it is important to make sure that work is well defined and that communications are in place to allow remote workers to work effectively. Several products are available to assist individual consumers and organizations with communications. Many products were developed or enhanced in recent years to address the issue of providing fast, convenient, consistent, and up-to-date project information. Webcasts are now a common tool for presenting video, graphics, sound, voice, and participant feedback live over the Web. Podcasts and YouTube videos have also become popular tools for providing various types of audio and video information, from exercise instructions to class lectures. Most working adults and students have cell phones that they use to take and send pictures or send and receive text messages or . Many high school or college students text or tweet their friends to plan social activities or discuss academic topics. These same technologies can enhance project communications. For even more powerful and integrated communications, enterprise project management software provides many workgroup functions that allow a team of people at different locations to work together on projects and share project information. Workgroup functions allow the exchange of messages through , an intranet, wireless devices, or the Web. For example, you can use Project 2010 to alert members about new or changed task assignments, and members can return status information and notify other workgroup members about changes in the schedule or other project parameters. Microsoft Office Enterprise Project Management (EPM) Solution and similar products also provide the following tools to enhance communications: Portfolio management: By providing a centralized and consolidated view of programs and projects, the user can evaluate and prioritize activities across the organization. This feature makes it possible to maximize productivity, minimize costs, and keep activities aligned with strategic objectives. Resource management: Maximizing human resources is often the key to minimizing project costs. This feature enables the user to maximize resource use across the organization to help plan and manage the workforce effectively. Project collaboration: Sharing project information is often a haphazard endeavor. Project collaboration enables an organization to share knowledge immediately and consistently to improve communications and decision making, eliminate redundancies, and take advantage of best practices for project management. 220

221 Communication is among the more important factors for success in project management. While technology can aid in the communications process and be the easiest aspect of the process to address, it is not the most important. Far more important is improving an organization s ability to communicate. Improving this ability often requires a cultural change in an organization that takes a lot of time, hard work, and patience. IT personnel, in particular, often need special coaching to improve their communications skills. The project manager s chief role in the communications process is that of facilitator. Project managers must educate all stakeholders management, team members, and customers- on the importance of good project communications and ensure that the project has a good communications management plan. Case Study Christine Braun worked closely with Peter Gumpert and his project managers to develop a communications management plan for all of the fiber-optic undersea telecommunications projects. Peter was very skilled at running effective meetings, so everyone focused on meeting specific objectives. Peter emphasized the importance of keeping himself, the project managers, and other major stakeholders informed about the status of all projects. He emphasized that the project managers were in charge of their projects, and that he did not intend to tell them how to do their jobs. He just wanted to have accurate and consistent information to help coordinate all of the projects and make everyone s jobs easier. When some of the project managers balked at the additional work of providing more project information in different formats, Peter openly discussed the issues with them in more detail. He then authorized each project manager to use additional staff to help develop and follow standards for all project communications. Christine used her strong technical and communications skills to create a Web site that included samples of important project documents, presentations, and templates for other people to download and use on their own projects. After determining the need for more remote communications and collaboration between projects, Christine and other staff members researched the latest hardware and software products. Peter authorized funds for a new project led by Christine to evaluate and then purchase several smart phones, apps, and enterprise project management (EPM) software with wiki capability that could be accessed via the Web. All managers and technical staff received their own devices, and any project stakeholder could 221

222 request one and get one-on-one training for how to use it with the new apps and EPM software. Even Peter learned how to use one, and now doesn t know how he got along without it SUMMARY A big end result of communication is the ability to understand what is being communicated. Given that a lot of the time, understanding what people are saying involves appreciating the feelings that lie behind the reason for the discussion, you can only best understand what they are saying, and importantly why, if you are ableto empathise with them (share an understanding of the feelings behind what they are saying). The only way of achieving this in my experience is to spend time with people, fully engaged with them and prepared to experience the feelings which may be the key driver of that communication process. BEING THERE! If you do not attempt to engage at this level, the person you have communicated with may not believe you have fully understood, so feedback here is vital. BEING THERE is to be physically present, mentally present and demonstrating you are keen to understand. This is where your skills as a leader go hand in hand with your active communications skills KEYWORDS Communication frequency, Concise, Collaborative tool, Templates, Portfolio management, EPM Enterprise Project Management UNIT END EXERCISE 1. Explain Project Communication in detail. 2. Mention and explain the suggestions for improving project communication? 3. Explain the methods for developing better communication skill. 4. Explain the usage of software in assistance to Project Communication. 222

223 12.8 SUGGESTED READING 1. Information Technology Project Management Kathy Schwalbe, International Student Edition, THOMSON CourseTechnology, Software Project Management Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill 3. Microsoft Office Project 2003 Bible, Elaine Marmel, Wiley Publishing Inc. 223

224 Module-4 224

225 UNIT 13: RISK MANAGEMENT AND CASE STUDY Structure: Objectives Concepts of Risk and Risk Management Common sources of risk on its projects Risk Identification Risk Quantification Risk Response Risk Monitoring and Control Using software to assist in Project Risk Management Summary Keywords Unit-end exercises and answers Suggested readings OBJECTIVES At the end of this unit you will be able to Understand the primary objective of risk management Explain the concepts risk monitoring and control, risk response and risk quantification Elucidate the role of software to assist in project risk management 225

226 115.1 CONCEPTS OF RISKS AND RISK MANAGEMENT Risks are those events or conditions that may occur, and whose occurrence, if it does take place, has a harmful or negative effect on a project. Risks should not be confused with events and conditions that require management intervention or action. A project manager must deal with and plan for those situations that are likely to occur but whose exact nature is not known beforehand; such situations, however, are not risks. For example, it is almost certain that defects will be found during software testing, so a reasonable project must plan to fix these defects when they are found. Similarly, it is almost certain that some change requests will come, so project management must be prepared for changes and plan accordingly to handle such normal events. A risk, on the other hand, is a probabilistic event-it may or may not occur. For this reason, we frequently have an optimistic tendency to simply not see risks or to wish that they will not occur. Social and organizational factors also may stigmatize risks and discourage clear identification of them. This kind of attitude gets the project in trouble if the risk events materialize, something that is likely to happen in a large project. Not surprisingly, then, risk management is considered first among the best practices for managing large software projects. Risk management aims to identify the risks and then take actions to minimize their effect on the project. Risk management is a relatively new area in software management. It first came to the forefront with Boehm's tutorial on risk management. Since then, several books have targeted risk management for software. Before we discuss risks in the software context, let's examine the concept a bit more with the aid of an example. Consider a computer show for which an important goal is to provide uninterrupted computer services. For this goal, one clear risk is electric power failure. The power may or may not fail. If it does fail, even for a second, the computer services will be affected substantially. If this case is unacceptable, a universal power supply (UPS) can be deployed to minimize its consequences. If it is suspected that the power may go out for a long period, a backup generator may be set up to minimize the problem. With these risk management systems in place, if the power does go out, even for a long period, the show-related goal will not be compromised. The first thing to note from this example is that risk management entails additional cost. Here, the cost for the UPS and the generator is extra because these components would not be 226

227 needed if the risk of power failure did not exist. Hence, risk management can be considered costeffective only if the cost of risk management is considerably less than the loss incurred if the risk materializes. For example, if the loss due to power failure is low, the cost of a UPS is not justified-a situation that prevails, for example, in homes. Second, it is not easy to measure the value of risk management, particularly in hindsight. If the power fails for one-half hour during the show, the value provided by the UPS and generator might be calculated as the "savings" achieved by having the computers running while the power was out. Suppose, however, that the power supply does not fail even for a second and therefore the UPS and generator are not used. Does this mean that the expenditure on these components was a waste? No, because the power could have failed. If the risk does not materialize, the value of using risk management cannot be directly measured in terms of value or output produced. Because risk events likely occur infrequently, the chances are high that risk management systems will not be used during the project. It is this probabilistic nature of risks and the inability to always realize the direct value of risk mitigation efforts that make it difficult to manage risk. From this example, it is clear that the first step in risk management is to identify the possible risks and to assess the consequences. Once you have done risk assessment, you can develop a risk management plan. Overall, then, risk management has two key components: risk assessment and risk control. Each component involves different tasks, as shown in Figure 1. Figure 1: Risk management activities The purpose of the risk assessment task is to identify the risks, analyze them, and then prioritize them. In prioritizing risks, you identify the risks that should be managed. In other words, prioritization determines where the extra effort of risk management should be spent to get the maximum benefit. For this effort, two factors are important. First is the chance of a risk 227

228 occurring; a more likely risk is a natural candidate for risk management. Second is the effect of the risk; a risk whose impact is very high is also a likely candidate. One way to prioritize risks, therefore, is to estimate the probability of its occurrence and its consequences when it does occur. The product of these values, the expected value of the loss for the risk, can be used for prioritization. This expected value is called risk exposure. If Prob(R) is the probability of a risk R occurring and if Loss(R) is the total loss incurred if the risk materializes, then risk exposure, RE, for the risk is given by the following equation: RE (R) = Prob(R) x Loss(R) Once the risks have been prioritized, you must decide what to do about them. Which ones will be managed is a management decision. Perhaps only the top few need to be handled in a project. One approach is to take preventive or avoidance actions so that the perceived risk ceases to be a risk. For example, if new hardware is a risk, it could be avoided by implementing the project with proven hardware. Such actions, however, are not always feasible for example, if working with new hardware is a requirement from the customer. In such situations, the risks to the project must be handled properly. For each risk that will be handled, you must devise and then execute risk management plans. Because risk perception changes with time, you must also monitor both the risk and the execution of the plans to minimize its consequences. In a project, risk perceptions may evolve naturally, or the risk management plans put into action may reduce the risk. In either case, it is important to continually gauge the status of risks and their management plans. Risk management can be integrated in the development process itself, as is done in the spiral model of software development. If you treat risk management as a separate process, you must understand its relationship with project execution, depicted in Figure 2. As shown in the figure, risk assessment and monitoring take information from project execution, along with other factors, to identify risks to be managed. The risk management activities, on the other hand, affect the project's process for minimizing the consequences of the risk. 228

229 Figure 2: Risk management and project execution COMMON SOURCES OF RISK ON IT PROJECTS Several studies have shown that IT projects share some common sources of risk. For example, the Standish Group did a follow-up study to its CHAOS research called Unfinished Voyages. This study brought together 60 IT professionals to elaborate on how to evaluate a project s overall likelihood of being successful. Table 3 shows the Standish Group s success potential scoring sheet and the relative importance of the project success criteria. If a potential project does not receive a minimum score, the organization might decide not to work on it or to reduce the risks before the project invests too much time or money. Table 3: IT success potential scoring sheet Success Criterion Relative Importance User Involvement 19 Executive management support 16 Clear statement of requirements 15 Proper planning 11 Realistic expectations 10 Smaller project milestones 9 Competence staff 8 Ownership 6 Clear vision and objectives 3 Hard-working, focused staff 3 Total 100 The Standish Group provides specific questions for each success criterion to help decide how many points to assign to a project. For example, the following five questions are related to user involvement: Do I have the right users? 229

230 Did I involve the users early and often? Do I have a quality relationship with the users? Do I make involvement easy? Did I find out what the users need? The number of questions corresponding to each success criterion determines the number of points each positive response is assigned. For example, the topic of user involvement includes five questions. For each positive reply, you would get 15.8 (19/5) points; 19 represents the weight of the criterion, and 5 represents the number of questions. Therefore, you would assign a value to the user involvement criterion by adding 15.8 points to the score for each question you can answer positively. Many organizations develop their own risk questionnaires. Broad categories of risks described on these questionnaires might include: 1. Market risk: If the IT project will create a new product or service, will it be useful to the organization or marketable to others? Will users accept and use the product or service? Will someone else create a better product or service faster, making the project a waste of time and money? 2. Financial risk: Can the organization afford to undertake the project? How confident are stakeholders in the financial projections? Will the project meet NPV, ROI, and payback estimates? If not, can the organization afford to continue the project? Is this project the best way to use the organization s financial resources? 3. Technology risk: Is the project technically feasible? Will it use mature, leading-edge, or bleeding-edge technologies? When will decisions be made on which technology to use? Will hardware, software, and networks function properly? Will the technology be available in time to meet project objectives? Could the technology be obsolete before a useful product can be created? You can also break down the technology risk category into hardware, software, and network technology, if desired. 4. People risk: Does the organization have people with appropriate skills to complete the project successfully? If not, can the organization find such people? Do people have the proper managerial and technical skills? Do they have enough experience? Does senior management support the project? Is there a project champion? Is the organization familiar 230

231 with the sponsor or customer for the project? How good is the relationship with the sponsor or customer? 5. Structure/process risk: What degree of change will the new project introduce into user areas and business procedures? How many distinct user groups does the project need to satisfy? With how many other systems does the new project or system need to interact? Does the organization have processes in place to complete the project successfully? 1.3 RISK IDENTIFICATION In project management, risk identification begins at the earliest stages of a project and continues throughout the project life cycle. Project risks can include unknown issues and variability in cost, effort, timing, and benefits in relation to a specific project. As a project manager, it is your job to anticipate project risks and to implement the necessary controls before risks become insurmountable. Project managers typically classify risks as either "threats" or "opportunities." The practice of risk identification focuses on reducing the probability and impact of a threat while increasing the probability and impact of an opportunity. During the risk identification phase, a project manager must establish the various risk categories that are pertinent to the project before selecting the appropriate tools and techniques to identify risks. Categorizing risks Projects can include the following types of risks. Internal risks Internal, nontechnical risks are risks within the control of project managers. These risks usually arise from a failure of the project organization or resources (human, material, or financial) to achieve their expected performance. Internal risks might result in schedule delays, cost overruns, or interruptions in cash flow. You can categorize these risks as threats or opportunities. Internal, technical risks are those arising directly from the technology of the project or the work environment. Technical risks might include the design, construction, or operation of the 231

232 facility, or the design of the product. These risks can arise from product changes or from a failure to achieve the needed levels of performance. External risks External, predictable risks are beyond the control of project managers. As a project manager, you must be ready to encounter these risks; however, more important is what you do to counteract them. External, predictable risks include market activity (such as Wall Street activity); fiscal policies affecting currency, inflation, and taxation; environmental factors (such as weather); or social impacts. These risks also can be categorized as threats or opportunities. External, unpredictable risks are beyond the control of project managers and are almost always categorized as threats. Identifying risks It is vital for project managers to be risk-aware. By being aware of possible risks, you will be able to respond quickly if a problem occurs. Also, if the unexpected occurs, you will be able to focus your management efforts on the problems that cause the greatest disruption. Use of experts As the project manager, you continue through the risk identification process by assembling the project team and explaining the objectives of managing the risks in an appropriate and proactive manner. You must remain firmly in control at every stage of the process. You can select experts to assist in the identification of risk scenarios. Experts should be knowledgeable individuals that have either an internal or an external affiliation to the project. External experts are useful to compensate for possible biases and to contribute independent views and opinions. The number of experts may vary from 3 to 4 for small projects, to 10 to 15 for larger projects. Work Breakdown Structure A Work Breakdown Structure (WBS) discloses risks that are inherent in the interdependency of the project work. Any event that lies at the start or completion of any of the project-related activities is a potential risk. These risks occur at clogging points in the network 232

233 when analysing the project plan. It's a good idea to look at all external interfaces, such as external supply, for potential failures by third parties. Interviews and brainstorming sessions As project manager, you can perform structured interviews and brainstorming sessions with experts to help identify project risks. For example, the Delphi method, which is a technique for problem solving and decision-making, permits you to harness the knowledge, expertise, and abilities of an entire group of disparate people. By using the Delphi Method, open-ended questions are posed to explore all facets of risk scenarios, and as a result, experts are used to arrive at a consensus. By using this type of analysis, a project manager attempts to determine the probability of occurrence and the performance, cost, and schedule impacts if the risk occurs. Another useful strategy for identifying risk is brainstorming. Brainstorming is an efficient method that uses social interaction to enhance the risk identification process. It requires a competent and unbiased facilitator to help keep the discussion on topic. It is possible that dominating individuals will attempt to push their ideas onto the rest of the group, and weaker personalities might not get a chance to air their views. The interviewer or brainstorming facilitator must have control of the situation and must think of a risk in terms of a what-if statement. The risk statements are the basis for analysis. An example of a poor risk statement is "communication is a problem." A more effective risk statement is "If we fail to communicate clearly, then effort will be wasted on resolving misunderstandings." Other tools and techniques Some other tools and techniques that are often used to enhance the risk identification process during interviews or brainstorming session include: A risk identification questionnaire is a document used to help team members identify project and technical risks. A risk identification questionnaire is a great document to share with key stakeholders early in the project cycle. 233

234 A Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis helps you to focus your risk identification assessment on the strengths and opportunities of your project as well as the threats and weaknesses. An influence diagram is a simple visual representation of a decision problem. Influence diagrams offer an intuitive way to identify and display the essential elements, including decisions, uncertainties, and objectives, and how they influence each other. Influence diagrams show how risks influence one another. The power of this technique is to identify areas of influence. Assumption Analysis is a win/lose analysis. It focuses on events that might be detrimental to the project. It considers events a project manager wants to occur but might not occur, and events a project manager does not want to occur but might occur. Managing risk After you have identified and documented the potential risks in your project, you need to consolidate and categorize them. By managing risks, you eliminate duplication and mediate the different views that are expressed. You then submit the results to the project team to obtain their concurrence for the data that was gathered. The feedback from the project team can then be used as input in the next phases of risk management process. The focus of the process can then shift to Risk Analysis, Risk Response Planning, and Risk Monitoring and Control RISK QUANTIFICATION Risk quantification involves evaluating risks and risk interactions to assess the range of possible project outcomes. It is primarily concerned with determining which risk events warrant response. It is complicated by a number of factors including, but not limited to: Opportunities and threats can interact in unanticipated ways (e.g., schedule delays may force consideration of a new strategy that reduces overall project duration). A single risk event can cause multiple effects, as when late delivery of a key component produces cost overruns, schedule delays, penalty payments, and a lower-quality product. Opportunities for one stakeholder (reduced cost) may be threats to another (reduced profits). 234

235 The mathematical techniques used can create a false impression of precision and reliability. Inputs to Risk Quantification Stakeholder risk tolerances: Different organizations and different individuals have different tolerances for risk. For example: A highly profitable company may be willing to spend $500,000 to write a proposal for a $1 billion contract, while a company operating at break-even is not. One organization may perceive an estimate that has a 15 percent probability of overrunning as high risk, while another perceives it as low risk. Stakeholder risk tolerances provide a screen for both inputs and outputs to risk quantification. Sources of risk: The first key to managing risk on your project is to know where to look for it. The good news is that 80% or more of all risks originate from the same sources on every project. Once you know the project characteristics that contribute to higher risk levels and the common sources of most project risks, you can quickly and effectively identify risk factors for any project. These factors should be first evaluated during project definition and will be the main reason why several iterations of planning are often necessary. In Table 1, most of the key project risk factors are listed to better guide your risk identification activities. Risk Source Category Project size and complexity Requirements Change Impact Organization Common Sources of Risk Examples/ Factors Effort hours Calendar time Estimated budget Team size (number of resources) Number of sites Volatile requirements Unrealistic or aggressive performance standards Complex requirements Replacement or new system Impact on business policies Impact on business processes Changes to project objectives Lack of priorities Lack of project management buy-in and support 235

236 Sponsorship Stakeholder involvement Schedule Funding Facilities Team Technology Vendors and Suppliers External factors Project Management Lack of strong executive commitment Lack of clear ownership Loss of political support All key stakeholders not identified Missing buy-in from a key stakeholder Stakeholder needs not completely identified Key stakeholders not fully engaged Estimate assumptions are not holding true Schedule contingency is not adequate Reduction in available capital Cash flow issues Inflation or exchange rate factors Adequate for team productivity requirements Adequate for project security requirements Full-time or part-time roles Location of team members Missing technical data Use of unproven technology Use of non-standard technology Contract types Risk-reward elements Procurement process Changing weather conditions Changes in legal and regulatory environment Approvals from governmental agencies Political changes Lack of experience Poor leadership Poor communications Some of the other Input Risk Quantifications are: Cost estimates Tools and Techniques for Risk Quantification Expected monetary value. Expected monetary value, as a tool for risk quantification, is the product of two numbers: Risk event probability--an estimate of the probability that a given risk event will occur. 236

237 Risk event value--an estimate of the gain or loss that will be incurred if the risk event does occur. The risk event value must reflect both tangibles and intangibles. For example, Project A and Project B both identify an equal probability of a tangible loss of $100,000 as an outcome of an aggressively priced proposal. If Project A predicts little or no intangible effect, while Project B predicts that such a loss will put its performing organization out of business, the two risks are not equivalent. In similar fashion, failure to include intangibles in this calculation can severely distort the result by equating a small loss with a high probability to a large loss with a small probability. The expected monetary value is generally used as input to further analysis (e.g., in a decision tree) since risk events can occur individually or in groups, in parallel or in sequence. Statistical sums. Statistical sums can be used to calculate a range of total project costs from the cost estimates for individual work items. The range of total project costs can be used to quantify the relative risk of alternative project budgets or proposal prices. Simulation: Simulation uses a representation or model of a system to analyze the behaviour or performance of the system. The most common form of simulation on a project is schedule simulation using the project network as the model of the project. Most schedule simulations are based on some form of Monte Carlo analysis. This technique, adapted from general management, "performs" the project many times to provide a statistical distribution of the calculated results. The results of a schedule simulation may be used to quantify the risk of various schedule alternatives, different project strategies, different paths through the network, or individual activities. Schedule simulation should be used on any large or complex project since traditional mathematical analysis techniques such as the Critical Path Method (CPM) and the Program Evaluation and Review Technique (PERT) do not account for path convergence and thus tend to underestimate project durations. Monte Carlo analysis and other forms of simulation can also be used to assess the range of possible cost outcomes. 237

238 Decision trees: A decision tree is a diagram that depicts key interactions among decisions and associated chance events as they are understood by the decision maker. The branches of the tree represent either decisions (shown as boxes) or chance events (shown as circles). Expert judgment: Expert judgement can often be applied in lieu of or in addition to the mathematical techniques described above. For example, risk events could be described as having a high, medium, or low probability of occurrence and a severe, moderate, or limited impact. Outputs from Risk Quantification Opportunities to pursue, threats to respond to: The major output from risk quantification is a list of opportunities that should be pursued and threats that require attention. Opportunities to ignore, threats to accept: The risk quantification process should also document (a) those sources of risk and risk events that the project management team has consciously decided to accept or ignore and (b) who made the decision to do so RISK RESPONSE All key risks identified should be responded to; however not all these risks will require treatment. The risks that fall outside of the Institution's risk tolerance levels are those which pose a significant potential impact on the ability of the Institution to achieve set objectives and therefore require treatment. The purpose of responding and treating risks is to minimize or eliminate the potential impact the risk may pose to the achievement of set objectives. Risk response is concerned with developing strategies to reduce or eliminate the threats and events that create risks. Risk response should also make provision for the exploitation of opportunities to improve the performance of the Institution. Responding to risk involves identifying and evaluating the range of possible options to mitigate risks and implementing the chosen option. Management should develop response strategies for all material risks, whether or not the management thereof is within the direct control of the Institution, prioritizing the risks exceeding or nearing the risk appetite level. Where the management of the risk is within the control of the Institution, the response strategies should consider: 238

239 Avoiding the risk by, for example, choosing a different strategy or terminating the activity that produces the risk; Treating the risk by, for example, implementing or improving the internal control system; Transferring the risk to another party more competent to manage it by, for example, contracting out services, establishing strategic partnerships and buying insurance; Accepting the risk where cost and strategy considerations rule out alternative strategies; and Exploiting the risk factors by implementing strategies to take advantage of the opportunities presented by such risk factors. In instances where the management of risk is not within the control of the Institution, the response strategies should consider measures such as forward planning and lobbing. Response strategies should be documented and the responsibilities and timelines attached thereto should be communicated to the relevant persons. Developing a risk response strategy Risk response plans identify responsibilities, schedules, the expected outcome of responses, budgets, performance measures and the review process to be set in place. The risk response plan usually provides detail on: Actions to be taken and the risks they address; Who has responsibility for implementing the plan; What resources are to be utilized; The budget allocation; The timetable for implementation; and Details of the mechanism and frequency of review of the status of the response plan. How to respond to risks? Responding to risks involves the following key steps, each of which is covered in detail in this section: 239

240 Identify risk response options; Select risk response options; Assign risk ownership; Prepare risk response plans; and Identify risk response options. Identify risk response options Risk response design should be based on a comprehensive understanding of how risks arise. This includes understanding not only the immediate causes of an event but also the underlying factors that influence whether the proposed response will be effective. Risk response options are not necessarily mutually exclusive or appropriate in all circumstances. They should include the following: Avoiding risk not engaging in the activity that creates risk exposure; Mitigating risk applying procedures that reduce the risk; Transferring risks transferring the risk exposure to other parties; Exploiting risk exploiting risks that represents missed opportunity; Accepting risk accepting a risk with a low level of exposure; Terminating risk stopping the activity that gives rise to a risk higher than the acceptable level; and Integrating some risks applying some or all of the risk response to a address a risk. Select options for response Once risks have been assessed and a level of risk rating has been assigned, an option for response is selected. Consideration should be given to the cost of the response option as compared to the likely risk reduction that will result. In order to understand the costs and benefits associated with each risk response option, it is necessary to conduct a cost-benefit analysis. Basic cost benefits analysis includes: Defining or breaking down the risk into its elements by drawing up a flowchart or list of inputs, outputs, activities and events; Calculating, researching or estimating the cost and benefit associated with each element. 240

241 Comparing the sum of the costs with the sum of the benefits. Assign risk ownership The Accounting Officer / Authority typically allocate responsibility for risk to an operational or functional area Line Manager. Risk owners nominated by Executive Management should assume responsibility for developing effective risk response plans. The risk owner (the person accountable for managing a particular risk) should be a senior staff member or Manager with sufficient technical knowledge about the risk and/or risk area for which a response is required. The risk owner will often delegate responsibility (but not accountability) to his / her direct reports or consultants for detailed plan development and implementation. Prepare response plans Once response options for individual risks have been selected, they should be consolidated into risk action plans and/or strategies. As one risk response may impact on multiple risks, response actions for different risks need to be combined and compared so as to identify and resolve conflicts between plans and to reduce duplication of effort. Response plans should: Identify responsibilities, schedules, the expected outcome of responses, budgets, performance measures and the review process to be set in place include mechanisms for assessing and monitoring response effectiveness, within the context of individual responsibilities; Institution's objectives, and processes for monitoring response plan progress against critical implementation milestones. This information should all arise from the response design process RISK MONITORING AND CONTROL The best risk planning in the world isn t any use unless you have a clear picture of how the situation in your project is developing in reality. You need to keep track of the identified 241

242 risks, monitor the effectiveness of your risk responses and identify new or changed risks. This means having effective reporting mechanisms in place and ensuring that risk is covered in all key reports and reviews. Most of the key issues are covered in the section on managing project phases in the Project Management info kit. You need to be on the lookout for the early warning signs or triggers you identified. The classic project risk trigger scenario is of course your most casual employee coming to work in a suit and asking for the afternoon off Effective monitoring and control also involves creating the right conditions for openness and transparency in the project. If you have a tendency to shoot the messenger then people will try to hide problems until the last possible minute by which time your range of response options may have narrowed. A key role of the project managers is also to communicate risk to the stakeholders. Senior managers hate surprises so you need to keep reminding them These are the top 5 risks we are facing at the moment so that when one of the risks occurs they are prepared for it. When a risk does occur and it will don t panic! Implement your planned response and communicate the fact that the risk was anticipated and plans were in place. Those of us who dislike documentation be warned the details in your risk log may be of critical importance if you are called to account for your assessment of, or response to, the risk. This should have been reviewed by your Steering Group or equivalent so you are able to say This is what we agreed. On the upside your review may reveal risks whose time has been and gone without them ever occurring. In these cases you may be able to hand back contingency funds to the organization. Business case At various points in this info kit we have returned to the business case behind the project. Risk analysis and management is an important part of assessing whether the business case for a project really stacks up. Your risk identification may show more serious risks than had been anticipated this means the business case must be reviewed. The emotional or subjective element in decision-making comes to the fore here. As a project manager you may be pushing your organization to undertake a risky project because otherwise you won t have a job. Conversely the organization may be so risk averse that it is missing opportunities. 242

243 Your analysis of acceptable and unacceptable risks may reveal one or more potential show stoppers in the unacceptable risks. In this situation the project shouldn t go ahead until the risk has been addressed. You may also need to review the business case in the event of a lot of risks being realized. Say you have assumed that 1 in 5 of the identified risks will occur but in practice most of them are happening maybe external factors have changed and the business case doesn t stack up any more. You mustn t lose sight of the bigger picture for organizational risk management. Creating a risk-robust culture Changing our organizational cultures to be more risk-robust isn t going to happen overnight. However the more we talk about risk in relation to projects and try to give concrete examples of how risks will impact then the more likely it is that our stakeholders will begin to have more realistic expectations of real world projects. Risk won t go away simply because we choose to ignore it or fail to plan for it. If we can start to create plans and budgets with risk factored into them then our organizations will develop a greater degree of confidence in their own abilities to manage projects and will be in a better position to evaluate their own risk tolerance. We must not lose sight of the fact that risks can be turned into opportunities and a proactive approach to risk management is a first step in creating new opportunities as an organization USING SOFTWARE TO ASSIST IN PROJECT RISK MANAGEMENT As you saw in several parts of this chapter, you can use a variety of software tools to enhance various risk management processes. Most organizations use software to create, update, and distribute information in their risk registers. The risk register is often a simple Microsoft Word or Excel file, but it can also be part of a more sophisticated database. Spreadsheets can aid in tracking and quantifying risks, preparing charts and graphs, and performing sensitivity analysis. Software can be used to create decision trees and estimate expected monetary value. More sophisticated risk management software, such as Monte Carlo simulation software, can help you develop models and use simulations to analyze and respond to various risks. 243

244 Several high-end project management tools include simulation capabilities. You can also purchase add-on software to perform Monte Carlo simulations using Excel or Project Several software packages have also been created specifically for project risk management. Although it has become easier to do sophisticated risk analysis with new software tools, project teams must be careful not to rely too heavily on software when performing project risk management. If a risk is not identified, it cannot be managed, and intelligent, experienced people are needed to do a good job of identifying risks. It also takes hard work to develop and implement good risk response strategies. Software should be used as a tool to help make good decisions in project risk management, not as a scapegoat when things go wrong. Well-run projects, like a master violinist s performance, an Olympic athlete s gold medal win, or a Pulitzer Prize-winning book, appear to be almost effortless. Those on the outside-whether audiences, customers, or managers-cannot observe the effort that goes into a superb performance. They cannot see the hours of practice, the edited drafts, or the planning, management, and foresight that create the appearance of ease. To improve IT project management, project managers should strive to make their jobs look easy-it reflects the results of a well-run project SUMMARY Risk events are situational, interdependent, value-based and time based. Risks reviews are not precise Risk identification is a team activity Although there are six steps to risk management, there are basically four processes: identification, quantification, response development, and control. Risks can be positive or negative. Mostly, they are negative KEYWORDS CPM Critical Path Method, PERT Program Evaluation and Review Technique, WBS Work Breakdown Structure, Delphi method, Monetary value. 244

245 UNIT END EXERCISE 1. What is Risk and Risk Management? Explain 2. Explain the common source of risk associated with the project. 3. Explain the following in detail: a) Risk Identification b) Risk Quantification c) Risk Response d) Risk Monitoring and Control 4. How does software assist in Project Risk Management? Explain SUGGESTED READING 1. Information Technology Project Management Kathy Schwalbe, International Student Edition, THOMSON CourseTechnology, Software Project Management Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill 3. Microsoft Office Project 2003 Bible, Elaine Marmel, Wiley Publishing Inc. 4. Basics of Software Project Management, NIIT, Prentice-Hall India, Software Project Management in Practice, Pankaj Jalote, Pearson Education, Software Project Management, A Concise Study, S.A. Kelkar, Revised Edition, Prentice HallIndia,

246 UNIT 14: PROCUREMENT PROCEDURES Structure: 14.0 Objectives 14.1 Introduction 14.2 Procurement Definition 14.3 Procurement Management Approach 14.4 The importance of Project Procurement Management 14.5 Procurement Plan 14.6 Solicitation Plan 14.7 Summary 14.8 Keywords 14.9 Unit-end exercises and answers Suggested readings 14.0 OBJECTIVES At the end of this unit you will be able to Understand the basic definition of procurement. List out the importance of project procurement management. Support Operational Requirements Manage the Procurement Process and the Supply Base Efficiently and Effectively Develop Strong Relationships with Other Functional Groups Support Organizational Goals and Objectives Understand the concepts with case Study 246

247 14.1 INTRODUCTION Project procurement management is about establishing, maintaining and closing relationships with suppliers of goods and services for the project. The processes for project procurement management from the PMBOK are outlined here and we will also look at a model for project supply chain management that has been developed for the construction industry. The definition of project procurement management from the PMBOK is: The processes necessary to purchase or acquire the products, services, or results needed from outside the project team There are four major processes: 1. Plan procurements 2. Conduct procurements 3. Administer procurements 4. Close procurements The purpose of the Procurement Management Plan is to define the procurement requirements for the project and how it will be managed from developing procurement documentation through contract closure. The Procurement Management Plan defines the following: Items to be procured with justification statements and timelines Type of contract to be used Contract approval process Decision criteria Establishing contract deliverables and deadlines Vendor Management Performance metrics for procurement activities This Procurement Management Plan sets the procurement framework for this project. It will serve as a guide for managing procurement throughout the life of the project and will be updated as acquisition needs change. This plan identifies and defines the items to be procured, the types of contracts to be used in support of this project, the contract approval process, and decision criteria. The importance of coordinating procurement activities, establishing firm contract deliverables, and metrics in measuring procurement activities is included. 247

248 14.2 PROCUREMENT DEFINITION The purpose of procurement definition is to describe, in specific terms, what items will be procured and under what conditions. Sometimes items which must be procured for a project can be made internally by an organization. Additionally, procurement deadlines are usually affected by the project schedule and are needed by certain times to ensure timely project completion. This section is where these items must be listed, justified, and the conditions must be set. Any important technical information should also be included. Individuals may also be listed with authority to approve purchases in addition to or in the absence of the project manager PROCUREMENT MANAGEMENT APPROACH The Procurement Management Plan should be defined enough to clearly identify the necessary steps and responsibilities for procurement from the beginning to the end of a project. The project manager must ensure that the plan facilitates the successful completion of the project and does not become an overwhelming task in itself to manage. The project manager will work with the project team, contracts/purchasing department, and other key players to manage the procurement activities. Procurement management is the process that involves purchasing or acquisition of products, service or results needed from outside the project team to perform a project at stake. Procurement management includes the contract management and change control processes; administering any contract issues by the buyer organization that is acquiring the project, being it services or product from the seller organization and contractual obligation placed on the team. The Project Manager will provide oversight and management for all procurement activities under this project. The Project Manager will work with the project team to identify all items to be procured for the successful completion of the project. The Project Management Office (PMO) will then review the procurement list prior to submitting it to the contracts and purchasing department. The contracts and purchasing department will review the procurement items, determine whether it is advantageous to make or buy the items, and begin the vendor selection, purchasing and the contracting process. 248

249 Project procurement management is more important to project management than most non-project managers realize. Project managers tend to work on one of two types of projects: 1) Internally-funded-i.e. projects where an organization wants to change its operations and commissions a project manager to make that change 2) Externally-funded-i.e., projects where a project organization is contracted to supply a specified product, e.g. a subsystem or a consumable service to the customer organization. A tiered arrangement is not uncommon in large complex projects with a customer, a supplier (often called the prime contractor) and component suppliers (often called subcontractors), each with a project manager looking after the interests of their employers. As part of this fiduciary responsibility, each project manager needs to understand and manage procurement from both the buying side of obtaining services and equipment and from the selling side, in terms of preparing tenders or quotes to their particular customer. Project procurement management is a fairly simple activity comprising four main processes; however, it can easily trip up a project manager and cause major delays that may result in payouts. The PMBOK Guide project procurement management processes comprise: plan procurements conduct procurements administer procurements Close procurements. Plan procurements is where the project manager makes the decisions about what has to be bought and how it is to be bought. Starting with the WBS, the project manager has to: Decide what items will be made within the project and what will be sourced from outside of the project Produce a statement of work (SOW) specifying each item so that the project team can build their components and suppliers can prepare proposals to supply project components Decide, and obtain agreement about, how to select the best proposal Decide what type of contractual arrangement is best for each project item to be purchased. 249

250 Project procurement tools and techniques The project team and the organization, needs to decide whether to make the required item inhouse or to buy the capability from an outside source. To make this decision, the project manager and the organization needs to assess whether making the item is within the organization s capability. If not, the organization will have to decide if the ability to make the item and support it throughout its life is in the strategic interests of the organization. Project managers will need to draw support and guidance from a range of subject matter experts when making procurement decisions. A project manager will generally need guidance with: Procurement process Contract Technical content Many project procurements are simple product purchases where the seller sets the conditions and the buyer (the project) agrees, purchases the item and pays the bill. Documentation is likely to consist of a purchase order, receipt of goods, invoice and statement. Fundamentally, this is not much more complex than buying groceries. However, a reasonable portion of project procurement involves buying complex goods and services that require the construction of a purchase-specific contract by a lawyer or procurement expert. Simplistically, a contract is a commercial agreement, of legal standing, between two parties identifying what each will do for or expects from the other. Broadly, there are three types of contracts, with many variations based upon this dichotomy. The difference lies in the level of commercial risk borne by each party and the type of work management undertaken by each of the parties. The basic contract types are: Fixed price (sometimes referred to as firm fixed price) the buyer pays the seller a set amount regardless of the seller's costs; the seller bears the risk of any cost overruns Cost reimbursement the buyer pays to the seller the seller's actual costs, plus a fee typically representing the seller's profit; the buyer bears the risk of any cost overruns Time and material (T&M) strictly speaking a cost-reimbursement contract. T&M contracts are treated as a special case of cost plus usually used for activities such as professional services. 250

251 It should be noted, that in Australia at least, it is impossible to include punitive penalties in a contract. In a failed contract, an Australian court will only award real and incurred costs (and sometimes lost profits), but not penalties. While cost plus contracts are common for labor hire, including professionals (doctors, dentists, contractor and consultants) the goals of the seller and the goals of the buyer are not aligned. The buyer wants to keep their costs (the price) down, but the seller wants to increase the overall price to increase their profit. Therefore, cost plus contracts involve a need for the buyer to control the work being done by the seller. This is relatively easy when one or two people are involved, but virtually impossible when tens or even hundreds are people are involved across multiple sites. The types of cost plus contracts: Cost plus fee (CPF) or cost plus percentage fee (CPPF) Cost plus fixed fee (CPFF) Cost plus incentive fee (CPIF) Cost plus award fee (CPAF) Time and material contracts (T&M contracts) are similar to cost plus contracts in that they reimburse for cost and effort, although T&M contracts often have a fixed contract element within them. In addressing the tools and techniques of conduct procurements we will change the order included in the PMBOK Guide and follow a logical, sequential approach. Expert guidance: The project manager will need to seek expert guidance to determining the best method to engage with the market to ensure that a wide range of sellers are aware of the project's procurement need. Independent estimates: This is another form of expert judgment. When you receive the responses to your RFT or RFP, how do you know if the prices are reasonable? How do you avoid paying too much? One tool to help with this is the independent estimate. Advertising: One of the key success factors to procurement is ensuring that the market knows that the project is actually seeking some form of goods and/or services. Bidder's conference:this is a briefing the buyer provides to the potential sellers. The briefing generally gives an overview of the statements of work and how bids will be evaluated and offers bidders the opportunity to ask questions. 251

252 Proposal evaluation techniques: Evaluation of complex responses will require evaluation by a team of different subject matter experts. This often results in a wide range of opinions between the subject matter experts as to which is the best proposal. One of the best ways for the project manager to address differing opinions and objectivity is to use a weighted decision-making technique such as Hurwicz Decision Criteria or the Kepner-Tregoe method. Procurement negotiation: Negotiation occurs after the best submission or proposal has been selected. Negotiation involves the buyer and seller meeting to discuss and resolve any differences in understanding the statement of work. The objective of the negotiation is to end up with a contract that both organizations can execute so the work can be delivered to the project. Records management: Within project procurement, a records management system (a subset of the project management information system PMIS) must be developed to keep track of: The contract baseline Approved contract changes Performance reports Claims Payments Performance assurance: Often some form of action is taken, especially on larger projects, to ensure that what the seller represents in their performance reports is what actually has happened. This is not an expression of distrust of the seller, but just prudent management to ensure the broader project does not receive unpleasant surprises Tools that can be used for performance assurance are: Procurement performance review-formal review of progress against schedule, cost and scope baselines involving both seller and buyer personnel who know about the project checking that work has been done correctly Inspections/audits-a more formal reviews that checks compliance of performance against requirement specifications. This is sometimes undertaken by a third party acting on behalf of the buyer. Procurement audit: At the end of a contract the seller will obviously seek final payment to close the contract. This is often initiated in the form of a completion certificate Negotiated settlement: unfortunately, at times, no agreement can be reached about how to resolve any remaining procurement issues. Options then available to the project manager are: 252

253 Escalation to the buyer's and seller's management teams to negotiate resolution of the issue. Seek a resolution through a formal mediation or arbitration process whereby the seller and buyer agree to whatever outcome the mediator deems fair. As a last resort, legal action through the court system Project procurement management artefacts INPUTS The key inputs to project procurement management are: Project management plan Project schedule Scope baseline Activity cost estimates Activity resource requirements Cost performance baseline Requirements documentation The key outputs include the: Procurement management plan: The procurement management plan is subordinate to and part of the overarching project management plan. The procurement management plan contains the project's intentions and plan for any procurement needed by the project, the processes to be followed and the associated roles, responsibilities and authorities. Statements of work: The statement of work (SOW) is the document provided to potential sellers that describes the work to be undertaken as part of that procurement contract. Make-or-buy decisions: This artefact is the documentation that captures the output of all makeor-buy decisions. Procurement documents: Procurement documents are simply the documents provided to a potential seller that specify the work that the buyer is seeking a proposal. Source selection criteria: This is the criteria that the buyer intends to use in evaluating each proposal. The criteria are often given to the sellers to enable them to understand what factors are 253

254 central to the buyer's procurement; however, the relative importance or weighting of criteria is not shared. change requests: When the contract is awarded, there may or may not be a need to update a range of plans to reflect any variation to cost, schedule or scope that resulted from the contract's negotiation. This should be fed through the project's change management system to ensure that all impacts are fully assessed and all parties are aware of these changes. Selected sellers: This involves preparing an evaluation report for senior management approval. This explains why a particular seller has been selected to provide products to the project. The organizational process assets are to be updated to reflect the completion of the procurement, i.e. archiving copies of the contract, contract changes, completion certificate, and copies of all correspondence, payment records, seller performance assessment and any lessons learned Project procurement management process The process for procurement management comprises: Plan procurements Conduct procurement Administer procurements Close procurements. In most functional organizations, there are very few people who can place orders for equipment or services and those few people tend to have a number of checks and processes designed to ensure that they are doing the right thing. The project's stakeholders are also likely to want to know who is making the decision on prime items of equipment and how that person will be making those decisions. The procurement plan needs to initially identify: What products or services need to be procured How the project will decide which products or services do need to be procured The process for advising the market of the procurement The process for selection of the candidate seller The process for approving the purchase decision. 254

255 When conducting procurement a project manager is exposed to a number of potential sellers all of whom want the project manager's business. Conducting procurements involves releasing procurement documents to the market, collecting proposals, analyzing those proposals, evaluating them and selecting the preferred seller. Having selected a seller and negotiated a contract, the project manager needs to administer the contract, i.e. track progress, and ensure that what was requested is in fact delivered and that payments are made as appropriate. Often this is left to other parts of the organization to manage; however, it is the project and, thereby the project manager, who experiences any contract mismanagement impacts. As such, the project manager needs to be fully aware of contract progress. Close procurements is the formal end of the contract. This is where the project accepts that it has received all the goods and services requested under the contract, in a fit-for-purpose condition and then pay the seller any remaining monies owed THE IMPORTANCE OF PROJECT PROCUREMENT MANAGEMENT Procurement means acquiring goods and services from an outside source. The term procurement is widely used in government; many private companies use the terms purchasing and outsourcing. Organizations or individuals who provide procurement services are referred to as suppliers, vendors, contractors, subcontractors, or sellers; of these terms, a supplier is the most widely used. Many IT projects involve the use of goods and services from outside the organization. The Project Management Institute defines an outside source as a source outside the project team, so the same organization can be a supplier to the project team, or the project team can be a supplier to another group in the organization. In fact, many IT departments in organizations are in direct competition with outside vendors, and they are subject to the same kind of requirements definition, statements of work, and bids. The rules and methods of sound project procurement practices are good to follow regardless of who provides the services to whom. Deciding whether to outsource, what to outsource, and how to outsource are important topics for many organizations throughout the world. 255

256 Because outsourcing is a growing area, it is important for project managers to understand project procurement management. Many organizations are turning to outsourcing to accomplish the following: Access skills and technologies: Organizations can gain access to specific skills and technologies when they are required by using outside resources. As mentioned earlier, a shortage of qualified personnel is the main reason that companies outsource IT services. A project may require experts in a particular field for several months, or it might require specific technologies from an outside source. Planning for this procurement ensures that the needed skills and technologies will be available for the project. Reduce both fixed and recurrent costs: Outsourcing suppliers often can use economies of scale that may not be available to the client alone, especially for hardware and software. It can also be less expensive to outsource some labor costs to other organizations in the same country or offshore. Companies can use outsourcing to reduce labor costs on projects by avoiding the costs of hiring, firing, and reassigning people to projects or paying their salaries when they are between projects. Allow the client organization to focus on its core business: Most organizations are not in business to provide IT services, yet many have spent valuable time and resources on IT functions when they should have focused on core competencies such as marketing, customer service, and new product design. By outsourcing many IT functions, employees can focus on jobs that are critical to the success of the organization. Provide flexibility: Outsourcing to provide extra staff during periods of peak workloads can be much more economical than trying to staff entire projects with internal resources. Many companies cite better flexibility in staffing as a key reason for outsourcing. Increase accountability: A well-written contract-a mutually binding agreement that obligates the seller to provide specified products or services and obligates the buyer to pay for them can clarify responsibilities and sharpen focus on key deliverables of a project. Because contracts are legally binding, there is more accountability for delivering the work as stated in the contract. The success of many IT projects that use outside resources is often due to good project procurement management. Project procurement management includes the processes required to acquire goods and services for a project from outside the performing organization. Organizations can be either the buyer or seller of products or services under a contract or other agreement. 256

257 There are four main processes in project procurement management: 1) Planning procurement management involves determining what to procure and when and how to do it. In procurement planning, one must decide what to outsource, determine the type of contract, and describe the work for potential sellers. Sellers are providers, contractors, or suppliers who provide goods and services to other organizations. Outputs of this process include a procurement management plan, procurement statements of work, procurement documents, source selection criteria, make-or-buy decisions, change requests, and project documents updates. 2) Conducting procurements involves obtaining seller responses, selecting sellers, and awarding contracts. Outputs include selected sellers, agreements, resource calendars, change requests, and updates to the project management plan and other project documents. 3) Controlling procurements involves managing relationships with sellers, monitoring contract performance, and making changes as needed. The main outputs of this process include work performance information, change requests, and updates to the project management plan, project documents, and organizational process assets. 4) Closing procurements involves completion and settlement of each contract or agreement, including resolution of any open items. Outputs include closed procurements and organizational process assets updates PROCUREMENT PLAN A market approach (procurement strategy) is prepared and adopted, defining the contracting arrangements that will be established to deliver the project. The approach to market must be fair, encourage competition and be consistent with government procurement obligations and agency procedures. The project procurement plan describes the stages of the project and how it will be managed. It should be consistent with the business case developed in previous step. Procurement Plan approval should be obtained prior to proceeding, confirming available funding and resources for managing the procurement. Deviations, if any, from the original business case should also be defined. 257

258 Establish governance structure A project team is appointed and roles and responsibilities allocated. Project governance and reporting structure and communication channels are also determined. The skills and experience of the team must be relevant to what is being procured Determine market approach (procurement strategy) The agency must first determine whether it is accredited to undertake the delivery phase of the project. If the agency is not accredited under the Agency Accreditation Scheme for Construction, it will need to obtain external support and assistance from an accredited agency or through the Procurement System for Construction. The market approach/procurement strategy outlines how the project will be executed. It depends on project characteristics such as its complexity and value and constraints such as timing, market capabilities and the effect on the agency's resources. The market approach includes the number, type, staging and inter-relationship of proposed contracts and the management structure. It may involve a single or multi-staged tendering process, depending on the nature of the project and the extent to which an innovative approach is required Prepare project procurement plan A procurement plan outlines the procurement strategy and market approach, the project brief and tender method. It builds on the business case/investment justification previously developed and includes a governance framework for the tender process and contract management. It proposes how tenderers will be selected, how the tender process will be managed and who will be responsible. It includes the basis for tender evaluation and a direct negotiations plan (if direct negotiations are involved). The procurement plan will also include key performance indicators for the proposed contract. A Gateway Review can be undertaken at the completion of this stage to confirm that the procurement strategy is appropriate to deliver the project within its budget and time constraints 258

259 and that the project is ready to proceed. Obtain approval to the procurement plan prior to proceeding. If the project is valued at $10 million or more, or is high risk, the procurement strategy report is to be submitted to Treasury SOLICITATION PLANNING In solicitation planning, several documents must be prepared by the procurement team. The first document, called the request for proposals (RFP), is used to solicit proposals from prospective sellers where there are several ways to meet the sellers needs. On the other hand, requests for quotes (RFQ) are used to solicit quotes for well-defined procurements invitations for bid or negotiation in which initial contractor responses are also part of solicitation planning. An RFP usually includes sections on the purpose of the RFP, the organization s background, requirements, environments, statement of work (SOW) with schedule, and required deliverables with schedule. Almost all mutually binding agreements or contracts include a SOW. Additionally; the contracting office will add boilerplate information required by law Completing Solicitation Planning Solicitation planning is the process of preparing to solicit sellers to provide products the project needs. It s a pretty straightforward business, as Figure 1 demonstrates. There are three inputs to solicitation planning. Procurement Management Plan: This subsidiary plan sets out the methodologies and expectations of procurement within the performing organization. Statement of Work: The SOW provides detailed information on what the seller will be providing for the performing organization. Recall that this document allows the seller to determine if it can provide the product and meet the requirements of the project team. Other planning outputs: Other details within the project plan, such as the schedules, estimates, constraints, and assumptions, are referenced as their values may have direct influence on the solicitation process. 259

260 Figure 1: Solicitation planning prepares the performing organization to solicit products from sellers Organizing Solicitation Materials Solicitation planning relies on the outputs of procurement planning. The Procurement Management Plan will guide the process as the project team has planned, as the performing organization requires, or under the guidance of a procurement office within the performing organization. There are two primary tools used for solicitation planning: Standard form: Within the performing organization, there may be many different standardized forms for contracts, descriptions of procurement items, bid documents, and other procurement related documents. Expert judgment: Expert judgment may be needed to review and help the project manager select the best source for the procured product Preparing for Solicitation Once the solicitation planning has been completed, the actual process of solicitation can begin. Fortunately, the sellers, not the buyers, perform most of the activity in solicitationsusually at no additional cost to the project. The sellers are busy trying to win the business. There are two inputs to solicitations: Procurement documents are created in solicitation planning. These are the Invitations for Bid, Request for Proposal, and Request for Quote documents. Qualified seller lists are often maintained by performing organizations. These lists of qualified sellers generally have contact information, history of past experience with the 260

261 seller and other pertinent information. In addition to the internal qualified seller list, there are many other resources to determine which sellers may qualify for the proposed work: Internet resources, industry directories, trade associations, and so on Completing Solicitation Solicitation is the processing of inviting sellers to solicit the business of the performing organization. There are two primary tools needed to complete this process: Bidder conferences: A bidder conference, also called a contractor conference or vendor conference, is a meeting with prospective sellers to ensure that all sellers have a clear understanding of the product or service to be procured and are all on equal footing. Bidder conferences allow sellers to query the buyer on the details of the product to help ensure that the seller s proposal is adequate and appropriate for the proposed agreement. At this point of the process, all sellers are considered equal. Advertising: In most circumstances, advertisements inviting bidders are expected. These advertisements can run in newspapers or trade journals specific to the industry of the organization. Some government agencies require advertisements inviting sellers to solicit the project work, attend a bidder conference, or present a proposal for the described work Examining the Results of a Solicitation The end result of a solicitation, as expected, is a collection of proposals, bids, and quotations. These documents indicate the sellers ability and preparedness to complete the project work. The proposals should be in alignment with the stated expectations of the buyer, and they may be presented orally, electronically, or in hard copy format. Of course the relationship between the buyer and seller-and the type of information being shared, will determine which modality is the best choice of communication SUMMARY In this unit, you have learnt the importance of procurement plans and the approach to procurement management plan. The importance of Project Procurement Management, Procurement plans and Solicitation planning have been discussed in detail. 261

262 14.8 KEYWORDS SOW Statement of Work, RFP Request for Proposal, RFQ Request for Quotes, PMIS Project Management Information System, T & M contracts Time and Material contracts, Solicitation UNIT END EXERCISE 1. What is Procurement? Explain Procurement Management approach in detail. 2. Explain the importance of Project procurement management. 3. Explain the following in detail: a) Procurement plan b) Solicitation planning SUGGESTED READING 1. Information Technology Project Management Kathy Schwalbe, International Student Edition, THOMSON CourseTechnology, Software Project Management Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill 3. Microsoft Office Project 2003 Bible, Elaine Marmel, Wiley Publishing Inc. 4. Basics of Software Project Management, NIIT, Prentice-Hall India, Software Project Management in Practice, Pankaj Jalote, Pearson Education, Software Project Management, A Concise Study, S.A. Kelkar, Revised Edition, Prentice HallIndia,

263 UNIT 15: Contract Administration Structure: 15.0 Objectives 15.1 Source Selection 15.2 Contract Administration 15.3 Performing contract close-out 15.4 Summary 15.5 Keywords 15.6 Unit-end exercises and answers 15.7 Suggested readings 15.0 OBJECTIVES At the end of this unit you will be able to know: Understand the source selection Explain the contract administration Performing contract close out 15.1 SOURCE SELECTION Source selection criteria are used to score seller proposals as part of the procurement process. The criteria could be subjective or objective and is generally specified as part of the procurement documents. Examples of source selection criteria include life cycle cost, technical capability of the seller, past performance of sellers, references and intellectual property rights. Source Selection Criteria It is very important for organizations to prepare some form of evaluation criteria for source selection, preferably before they issue a formal RFP. Organizations use criteria to rate or 263

264 score proposals, and they often assign a weight to each criterion to indicate its importance. Some examples of criteria and weights include the technical approach (30 percent weight), management approach (30 percent weight), past performance (20 percent weight), and price (20 percent weight). The criteria should be specific and objective. For example, if the buyer wants the supplier s project manager to be a certified Project Management Professional (PMP), the procurement documents should state that requirement clearly and follow it during the award process. Losing bidders may pursue legal recourse if the buyer does not follow a fair and consistent evaluation process. Organizations should heed the saying, Let the buyer beware. It is critical to evaluate proposals based on more than the professionalism of the paperwork submitted. A key factoring evaluating bids, particularly for projects involving IT, is the past performance record of the bidder. The RFP should require bidders to list other similar projects they have worked on and provide customer references for those projects. Reviewing performance records and references reduces the risk of selecting a supplier with a poor track record. Suppliers should also demonstrate their understanding of the buyer s need, their technical and financial capabilities, their management approach to the project, and their price for delivering the desired goods and services. It is also crucial to write the contract to protect the buyer s interests. Some IT projects also require potential sellers to deliver a technical presentation as part of their proposal. The proposed project manager should lead the potential seller s presentation team. When the outside project manager leads the proposal presentation, the organization can build a relationship with the potential seller from the beginning. Visits to contractor sites can also help the buyer get a better feeling for the seller s capabilities and management style. Determining Source Selection Once the sellers have presented their proposals, bids, or quotes (depending on what the buyer requested of them), their documents are examined so that the project manager can select which sellers are the best choice for the project work. In many instances, price may be the predominant factor for choosing a particular seller but not always. Other factors besides price may also be taken into consideration: The cost of an item may not reflect the true cost to the performing organization if the item cannot be delivered in a timely manner. If a seller promises to have a product on site 264

265 by a specific date and fails to do so, the project can be delayed, costing the organization thousands-or more-in losses. Proposals can be separated into two categories: technical and commercial. The technical category describes the approach and methodology to complete the project work. The commercial category delves into the price to complete the project work. An evaluation takes into consideration both categories in order to determine the best choice for the project. Critical, high-priority projects may rely on multiple sellers to complete the project work. This redundancy can balance risk, cost, and opportunity among multiple vendors. Preparing for Source Selection Source selection weighs and evaluates the proposals, bids, and quotes for the procured portions of the project and then makes a determination as to which seller is the best for the project work. Source selection has three inputs to the decision-making process: Proposals: The proposals, bids, and quotations provided by the sellers are key inputs. These are the documents the performing organization will evaluate to determine which seller is the best provider for the project. Evaluation criteria: The evaluation criteria, such as referrals, samples of previous work, and references are considered. The evaluation criteria are evidence of the quality, depth, and experience of work the seller has performed in the past and, hopefully, is capable of performing on the current project. Evaluation criteria are developed in solicitation planning and applied in source selection. Organizational policies: The performing organization likely has procurement policies and procedures the project manager is expected to follow in regard to source selection. The organizational policies should be known before starting the source selection process to avoid any discrepancies, conflicts of interest, or other breaches of the policies. For example, some organization s procurement policies do not allow project managers to accept any gifts beyond $25 in value. 265

266 Completing the Source Selection Process For the performing organization to finalize the process of source selection, there must first be eligible sellers. Assuming there is more than one seller that can satisfy the demands of the project, there are four tools and techniques the project manager can rely on: Contract negotiation: The performing organization creates an offer, and the seller considers the offer. The contract negotiation process is an activity to create a fair price for the work the seller is to complete. The performing organization and the seller must be in agreement on the expectations, requirements, authorities, terms, technical and business management approaches, price- and any other pertinent factors covered within and by the contract prior to signing the contract. Weighting system: A weighting system takes out the personal preferences of the decision-maker in the organization to ensure that the best seller is awarded the contract. Weights are assigned to the values of the proposals and each proposal is scored. Because the weights are determined before reviewing the proposals, the process is guaranteed to be free of personal preferences and bias. The seller with the highest score is awarded the contract. Screening system: A screening system is a method to remove sellers from consideration if they do not meet given conditions. For example, screening could require that sellers must be certified by a specific organization, have prior experience with the project technology, or meet other values. Sellers that don t meet the requirements are removed from the selection process and their proposals are not considered. Independent estimates: These estimates are often referred to as should cost estimates. These estimates are created by the performing organization, or outside experts, to predict what the cost of the procured product should be. If there is a significant difference between what the organization has predicted and what the sellers have proposed, either the Statement of Work was inadequate or the sellers have misunderstood the requirements. 266

267 Examining the Results of Source Selection The one output of source selection is a contract between the buyer and the seller.a contract is a legally binding agreement between the buyer and seller in which the seller provides the described product and the seller pay for the product. Contracts are known by many names: Agreement Subcontract Purchase order Memorandum of understanding Contracts have to be signed by a person with the power to authorize the requirements and payment specified in the contract. This role is called the delegation of procurement authority. Whether this person is the project manager depends on the procurement policies of the performing organization. In some organizations all contracts flow through centralized contracting. Centralized contracting requires all contracts for all projects to be approved through a central unit within the performing organization. Other organizations use a decentralized contracting approach, which assigns a contract administrator or contract officer to the project CONTRACT ADMINISTRATION Contract administration involves managing your contracts to make sure you comply with and fulfill the contract conditions. Good contract administration ensures customer satisfaction and minimizes disputes. Process Definition Contract Administration is the process for managing the contract and relationship between buyer and seller, reviewing and documenting how a seller is performing or has performed to establish required corrective actions. It s a process which both parties have to do for their own purpose. The Contract Administration process ensures that the seller s performance meets contractual requirements and that the buyer performs according to the terms of contract. Member of the Monitoring and Controlling Process Group: 267

268 Child process of Monitor and Control Project Work Member of knowledge Area Project Procurement Management The subject Procurement Management operates on the base of other contracts concerning concepts Tools and Techniques: A Contract change control system is the set of rules and procedures " by which the contract can be modified" Buyer conducted performance review " is a structured review of the seller's progress to deliver project scope and quality, within cost and schedule, as compared to the contract" Inspections and audits - if specified in the contract - may be required by the buyer and are supported by the seller Performance reporting is the base for evaluating a seller and his ability to fulfill the contract A Payment system should be used. Claims administration is the area of "contested changes and constructive changes where the buyer and the seller cannot agree on compensation for the change ". These claims must be documented and then resolved by administrating persons, organizations and so on A Records management system " is used by the project manager to manage contract documents and records ", it's used "to maintain an index of contract documents and correspondence, and assist with retrieving and archiving that documentation" Information technology can be used " to enhance the efficiency and effectiveness of contract administration by automating portions of the records management system " Process Output The Contract Documentation contains at least all contracts and may be added by additional documents like pre-versions or "unapproved contract changes" Requested Changes " may result from the contract administration process": both, the buyer and the seller may request a change which must get the "approval through the Integrated Change Control process" 268

269 Recommended Corrective Actions " is anything that needs to be done to bring the seller in compliance with the terms of the contract" without changing the content of the contract Updates of the Organizational Process Assets can be evoked by the correspondence which must be hold for the future, or by documented payment schedules and requests, or by seller performance evaluation documentation Updates of the Project Management Plan :: Procurement Management Plan are evoked by updates of the Procurement Management Plan Updates of the Project Management Plan :: Contract Management Plan are evoked by updates of the Contract Management Plan Output Using Successor Processes Successors using the initially generated output as own input: Integrated Change Control Contract Closure Close Project Processes using the updates as input: Plan Contracting Request Seller Responses Select Sellers Performing Contract Administration Contract administration is the process of ensuring that the seller lives up to the agreements in the contract. The project manager and the contract administrator must work together to make certain the seller meets its obligations. If the seller does not fulfill its contractual requirements, then legal remedies may ultimately be pursued. Another aspect of contract administration, especially on larger projects with multiple sellers providing various products, is the coordination between the contractors. The project manager or contract officer schedules and confirms the performance of the sellers so that the deliverables, schedule, and performance of a contractor do not infringe or adversely affect the performance of another contractor. 269

270 Within the contract there must be the terms for payment. Typically the performance and progress of the contractor is directly linked to payments it receives. The project manager must track performance and quality to approve or decline payment as needed. The contract should define the metrics for acceptance to avoid disagreements on performance. Preparing for Contract Administration The contract is needed as a guide for effective contract administration. The contract dictates the requirements and expectations of the seller and the buyer. The obligations of both parties should be in alignment with the contract; if not, disagreements, delays, and even work stoppage can ensue. In addition to the contract, there are three other inputs to contract administration: Work results: The seller s work results must be completed according to the requirements of the contract. As part of project plan execution, the seller must meet the quality standards of the performing organization and expected schedule of completion and stay within the anticipated costs and the specified range of variance. Change requests: Change requests can complicate contract administration. The performing organization s Change Control System has to mesh, somehow, with the seller s Change Control System. Changes to the project that affect the contracted work require changes to the contract, addendums to the contract, or a new contract for the additional or changed work. In some instances, the seller and the buyer may disagree about the cost of the changes. These differences may be labeled as claims, disputes, or appeals-they can ultimately slow the project progress if they are not remedied. Seller Invoices: Within the contract, the terms for payment are specified. The terms for payment may stipulate under what conditions the seller will provide an invoice for the work completed. In addition, the buyer may specify when and how the invoices are paid. On the Job If the seller s performance is unacceptable and a resolution to the problem cannot be found, the performing organization may elect to cancel the contract. This termination of the contract is also handled as a change request within the Change Control System. 270

271 Completing Contract Administration The actual process of completing contract administration relies heavily on communication between the project manager, the contract officer, and the seller. The communications plan may have considerations for how and when the communication between the buyer and seller should take place and what the purpose of the communication should be. There are three primary concerns, in addition to communication, within contract administration: Contract Change Control System: The contract change control system defines the procedures for how the contract may be changed. The process for changing the contract includes the forms, documented communications, tracking, conditions within the project, business, or marketplace that justify the needed the change, dispute resolution procedures, and the procedures for getting the changes approved within the performing organization. The system is part of Integrated Change Control. Performance Reporting: Performance reporting is the communication between the project manager and management on how the seller is performing under the guidelines in the contract. Performance reporting is part of communications and should be documented within the Communications Management Plan. Payment System: Sellers like to be paid when they have completed their obligations. How the sellers are paid is controlled by the payment system, which includes interaction of the project manager and the Accounts Payable department. The performing organization may have strict guidelines for how payment requests are submitted and approved and how payments are completed. On larger projects, the project management team may have specific procedures for submitting the payment requests. Reviewing the Results of Contract Administration Contract administration calls for communication between the seller and buyer, the project manager and the vendor, and the stakeholders. There must significant documentation of the agreement that both the buyer and the seller agree to before the procured work begins. Once the procured work, service, or product has been delivered from the seller to the buyer there needs must be agreement that the deliver is in alignment with the original agreement. As part of contract administrations there are three outputs of contract administrations: 271

272 Correspondence: The performance of the contracted work, the contract obligations, and the procedures of the performing organization generate correspondence between the buyer and seller. The correspondence often takes the form of warnings, letters of discontent, and project performance reviews from the buyer to the seller. This correspondence can serve as documentation for legal action if disputes arise between the buyer and seller. Contract Changes: Both approved and declined changes are documented as to their cost, time, and effect on the project and the procured work. Changes that are approved require updates to the project plan, subsidiary plans, and possibly to other project documentation. Payment requests: If the project is using an external payment system, there will be communication between the buyer and seller, and between the buyer and the external payment system. If the performing organization is handling its own payment processing, this output would simply be payments. Detailed Explanation Contract administration concentrates on the relationship between the department and the supplier from contract award to contract closeout ensuring the supplier delivers the product and/or service in conformance with the purchase document requirements. The contract administrator must completely understand all aspects of the purchase document. This chapter describes the DGS/PD requirements and recommended practices associated with contract administration activities Contract Administration Principles What s in a name: Personnel assigned to perform supplier performance and contract administration activities are often referred to as a contract manager or contract administrator. This chapter will refer to the person assigned to perform all contract administrative functions as a contract administrator. Buyers remain involved: Although contract administration assignments may be determined by departmental policies and procedures or the magnitude or complexity of the contract, it is critical that the buyer remains involved in the post award contract activities, including acting as the department s contract manager or as a liaison between the contracting parties and the DGS/PD as warranted. 272

273 Expectations of the contract administrator: Regardless of the title used, the person assigned contract administration functions must be made aware of the expectations and requirements of the position. A contract administrator must: o Have sufficient knowledge of contracting principles as it relates to their responsibilities in administering the contract. o Communicate with both the buyer and supplier on contractual issues. o Maintain records or logs to turn over to the procurement office at the completion of the contract. Establish the fundamentals: Once a purchase document has been executed, the contract administration responsibilities should be reviewed with the person assigned to the role. Any additional contract administration activities specific to the transaction should also be reviewed. Communication is key: A key factor in successful contract administration is communication. It is essential for contract administrators to understand the provisions of the purchase document, have the ability to communicate contract obligations to all parties involved, and maintain control over the contract performance. The Do s and Don ts of Contract Administration Contract administration do s Effective contract administration activities include: Notifying the contractor to begin work. Monitoring contract activities for compliance with: o Work progress to ensure IT services are performed according to the quality, quantity, objectives, timeframes, and manner specified within the contract. o SB and DVBE contractors and/or subcontractors to ensure attainment of approved contract participation goals. o Review progress reports, status reports, and timesheets as required. Approving the final product/it services by submitting a written document accepting the deliverables. Providing any documentation to the department s procurement office. 273

274 Monitoring expenditures, ensuring funding availability when contract extends over multiple years. Verifying accuracy of invoices and approving invoices for payment. Requesting amendments/addendums/supplements/changes and/or contract renewals in a timely fashion as determined by departmental policies and complexity of the request (often three six months in advance). Verifying all work is completed and accepted by the department prior to the contract expiration date. Performing contract close out activities: o Completing Contractor Evaluation Report for IT consulting services or in accordance with department policies and procedures. o Notifying responsible parties when funds can be disencumbered. Reporting any contract disputes immediately to the department procurement office. Keeping an accurate auditable paper trail of contract administration. Contract administration don ts Contract administrators are not authorized to: Instruct the contractor to start work before the contract is fully executed. Change the scope of the contract without doing so through the formal purchase document amendment process. Direct the contractor to perform work that is not specifically described in and funded by the contract. Extend the time period of the contract without execution of an approved amendments/addendums/supplements/changes. Allow the contractor to incur any additional costs over the limit set by the contract. Sign a contract as the department s authorized signatory unless authorized in writing. Sign any contractor s contract form. 274

275 Ethical Decision Making and Contract Administration Work behaviors and awareness Staff, other than buyers, that perform contract administration functions, not only need to understand how to administer a contract but are also expected to adhere to and conduct business by maintaining the same ethical standards as if they were a buyer. Review contract principles: Buyers that are turning over the contract administration functions to a person unfamiliar with the procurement process should review with that person the principles of conduct governing the acquisition process and its impact to the role of the contract administrator. Contract administrators must: o Conduct them in a professional manner, refraining from mixing outside friendships with business, not engaging in incompatible activities, conflicts of interest, or unethical behavior. o Accurately account for expenditures and property received. o Involve the department s procurement and legal resources staff when questions arise regarding acceptable or unacceptable behavior when dealing with suppliers. Ethics review Buyers and contract administrators are advised to review their department s statement of incompatible activities on ethics and prohibited practices, and refer to Procurement Planning. Record Retention and Contract Administration Good record keeping Departments are responsible for maintaining records in sufficient detail to allow anyone to review documentation and understand how the procurement was requested, conducted, awarded, and administered. Buyers shall provide contract administrators with the necessary instructions to maintain good record keeping activities and ensure the records are turned over to the procurement office at 275

276 the completion of the contract term. The records maintained by the contract administrator are incorporated into the procurement file and retained for compliance and/or auditing purposes. Setting up a contract file Contract administration responsibilities may also include establishing the department s procurement file dependent upon the department policies and procedures as to who performs the contract administration duties. Consequently, contract administrators should organize documentation according to department procurement processes in addition to the DGS/PD recommendations. The DGS/PD recommends creating files by: Developing a user-friendly filing system. File by purchase document number or supplier name. Establishing a separate hard copy file for each purchase document administered. Developing a log sheet for a diary of activities. This may include dates and times of discussion and subject matter discussed. Developing spreadsheets for tracking expenditures, invoices, and/or timekeeping for the life of the transaction. Creating file dividers for: o Original purchase document and all amendments/addendums/supplements/changes o Work Authorizations o Deliverables o Correspondence acceptance letters, termination notices, etc. Record retention requirements The Attorney General s Office has directed that in view of the need for purchase order and contract purchase files for antitrust litigation, such records should be retained for seven years from the end of the fiscal year in which encumbrance is liquidated. Destroy after the required seven years or when audited by the Bureau of State Audits or the Department of General Services, whichever comes first. 276

277 Since there are various sources that dictate records retention requirements (e.g. statute, policy, pending litigation, etc.) and the retention varies depending on document type and can vary by department, depending on their internal retention schedule, there is not a one size fits all retention rule. When in doubt, departments should retain for the longest period applicable PERFORMING CONTRACT CLOSEOUT Contract closeout is analogous to administrative closure. Its purpose is to confirm the obligations of the contract were met as expected. The project manager, the customer, key stakeholders, and, in some instances, the seller may complete product verification together to confirm that the contract has been completed. Contract closeout can also be linked to administrative closure, because it is the process of confirming the work was completed. In instances when the contract was terminated, contract closeout is reviewed and is considered closed because of the termination. The project records should be updated to reflect the contract closeout and the acceptance of the work or product. Reviewing Contract Documentation To successfully close out a contract, the details of the contract may need to be reviewed. This review ensures that the product verification is complete and in accordance with the language and agreement in the contract. The review actually considers more than just the contract; the project manager should review and consider the following: Schedules of the procured work Contract change requests-approved and declined Documentation the seller has created and provided, if any Financial documents, invoices, payment records Results of contractual inspections Auditing the Procurement Process The successes and failures within the procurement process of the project are reviewed from procurement planning stage through contract administration. The intent of the audit is to learn from what worked and what did not work during the procurement processes. This 277

278 knowledge can then be applied to other areas within the current project and to other projects within the performing organization. Completing Contract Closeout A contract file is a complete indexed set of records of the procurement process and is incorporated into the administrative closure process. These records include financial information as well as information on the performance and acceptance of the procured work. Assuming the procured work is acceptable and meets the requirements of the contract, the contract can be closed. The formal closure of a project comes in a written notice from the contract officer to the seller. The notice informs the seller that its work is acceptable and that the contract is considered closed. The formal closure process may vary according to the size of the project. The requirements for contract closeout should be documented within the contract SUMMARY In this unit, you have learnt the importance of source selection and the approach in contract administration in detail. The importance of Contract close-out have been discussed in detail KEYWORDS PMP Project Management Professional, Procurement process, Contract negotiation, Decentralized contract, Addendums UNIT END EXERCISE 1. What is Source selection? Explain 2. Explain the contract administration in detail. 3. How contract close is out performed? Explain 15.7 SUGGESTED READING 278

279 1. Information Technology Project Management Kathy Schwalbe, International Student Edition, THOMSON CourseTechnology, Software Project Management Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill 3. Microsoft Office Project 2003 Bible, Elaine Marmel, Wiley Publishing Inc. 4. Basics of Software Project Management, NIIT, Prentice-Hall India, Software Project Management in Practice, Pankaj Jalote, Pearson Education, Software Project Management, A Concise Study, S.A. Kelkar, Revised Edition, Prentice HallIndia,

280 UNIT 16: PROJECT MANAGEMENT PROCESS GROUPS Structure: 16.0 Objectives 16.1 Introduction to Project Management process groups 16.2 What is Project Management Plan? 16.3 Project initiation 16.4 Project planning 16.5 Project execution 16.6 Project monitoring and controlling 16.7 Project closing 16.8 Summary 16.9 Keywords Unit-end exercises and answers Suggested readings 16.0 OBJECTIVES At the end of this unit you will be able to know: Understand the Project management process and its plans Understand the initiation of project, its planning and the execution of project Understand the monitoring and control the flow of project Understand how the project is closed 280

281 16.1 INTRODUCTION: PROJECT MANAGEMENT PROCESS GROUPS It s important to understand that s going over the exact same aspects of running a project just from a different angle. Thus all process groups may have disciplines from one, several or all the knowledge areas covered in my last article. Using Project Management Institute s (PMI) definition of process groups and processes in this article. There are five fundamental process groups: Initiating Planning Executing Monitoring & Controlling Closing There are 44 PMI processes performed as part of a project and each one will be categorized into one of these process groups. These five Process Groups are the building blocks of every PMLC. In the simplest of cases, the Process Groups will each be completed once and in the sequence listed here. In more complex situations, some or all of them might be repeated a number of times. These five Process Groups are defined in PMBOK. What follows is my adaptation of these Process Groups for use in this book and to prepare you to adapt them for your own use. None of these adaptations contradict any of the principles underlying PMBOK. You may think that each process group is processed in order but that would be a mistake. A project s scope is progressively elaborated, which means that some processes are performed iteratively. For instance after planning you will execute and then monitor and control. This may cause you to act by changing the plan, then execute again, then monitor and control. It is also called the Plan-Do-Check-Act cycle of the project, a recursive cycle that eventually will end when we close the project. Initiating Process Group This is one of the simpler groups and here we basically develop a Project Charter and a Preliminary Project Scope Statement. In this group, the project is formally started, the project manager is named, and the preliminary project scope is established. 281

282 PMBOK calls this the Initiating Process Group. However, the term initiating can be confusing if you are new to project management. I find the term scoping to be clearer. This Process Group includes all processes related to answering the question "What do you need to do?" It does not include any processes related to doing any project work. That project work is defined in the Planning Process Group to be done later in the project life cycle. The Scoping Process Group also includes establishing the business success criteria that will be the metrics used to answer the question "How will you know you did it?" The Scoping Process Group includes the following processes: Recruiting the project manager Eliciting the true needs of the client Documenting the client's needs Negotiating with the client about how those needs will be met Writing a one-page description of the project Gaining senior management approval to plan the project As you can see, the successful completion of the Scoping Process Group is to gain the approval of senior management to move to the next phase of the project. In every PMLC, the next phase will be defined by the Planning Process Group. This direct linkage of the Scoping and Planning Planning Process Group This is by far the largest group of all the process groups. Even though it is the largest group, it doesn t mean that most of the time is spent on this group in the project. Project planning is very important and it touches all the Project Knowledge Areas. It involves planning and defining scope. A work break down structure (WBS) is created, activities are defined and a schedule is created. Project cost is estimated and budgeted. Quality, human resource, risk and purchases are planned. Most projects may not need comprehensive planning in all knowledge areas and some smaller projects may not have all areas included at all. The idea is that the project manager at least considers all the planning processes and makes his or her own decision how much planning is needed in each case. 282

283 The Planning Process Group includes all processes related to answering the question "How will you do it?" These processes are as follows: Defining all of the work of the project Estimating how long it will take to complete the work Estimating the resources required to complete the work Estimating the total cost of the work Sequencing the work Building the initial project schedule Analyzing and adjusting the project schedule Writing a risk management plan Documenting the project plan Gaining senior management approval to launch the project There are a number of ways that each of the processes in the Planning Process Group can be done. The way that they are done may be a function of the PMLC model being used or any of several other factors. I'll offer my experiences in executing each process and in many cases offer several alternative ways of conducting the process. Choosing which to use in a given situation is where organized common sense again takes its stance. Executing Process Group The executing processes typically involves the most work, because now the project is up and running. This group is concerned with directing and managing the execution of the project. It also involves performing quality assurance. Remember that quality assurance is not the same as quality control (which is in the monitoring and control group). Quality assurance is concerned with improving the overall process of quality control. PMBOK calls this the Executing Process Group. It is that and more. The Launching Process Group includes all processes related to recruiting and organizing the team and establishing the team operating rules. These processes are preparatory to executing the project. 283

284 The Launching Process Group also includes all of the processes related to getting the project work started. These would be the executing processes. The Launching Process Group includes the following processes: Recruiting the project team Writing a project description document Establishing team operating rules Establishing the scope change management process Managing team communications Finalizing the project schedule Writing work packages All of these processes relate more to the art of project management than to the science of project management. During the execution of this Process Group, the entire team may be coming together for the first time. There will be client members and your delivery team members present. Perhaps they are mostly strangers to one another. At this point, they are nothing more than a group. They are not yet a team but must become one in very short order. Thinking back over my early experiences as a project manager when meeting my team members for the first time, I think of my task to create a team as something akin to herding cats. You can't herd cats. There will be confusion and anxiety as they stare across the table at each other wondering why they are there, what they will be doing on the project, and what is happening on the project they should be working on in their home department. Being fully aware of this, the project manager will conduct that first team meeting with care, giving team members an opportunity to introduce themselves and what they bring to the project to the other team members. Monitoring and Controlling Process Group This group also touches each of the nine knowledge areas. It is basically to monitor the execution of the project. The group handles monitoring and controlling the project work. Change control and scope verification and control are performed. Schedule, cost, and quality are controlled also. Each knowledge area execution is essentially monitored and controlled in detail. 284

285 The Monitoring and Controlling Process Group includes all processes related to the ongoing work of the project. These processes are as follows: Establishing the project performance and reporting system Monitoring project performance Monitoring risk Reporting project status Processing scope change requests Discovering and solving problems Here is where the real work of the project takes place. It is a Process Group that consists of both the art and science of project management. It occupies the project manager with activities internal to the project team itself (mostly science but a dose of art as well) and with activities external to the project team and dealing with the client, the sponsor, and your senior management (mostly art but a dose of science as well). As problems and change requests arise, the strength of your relationship with your client will in large measure contribute to the success or failure of the project. Closing Process Group Here the project is closed. This process group is not concerned with customer acceptance like some may think. Customer acceptance is actually part of scope verification in the controlling process group. The project closure involves closing contracts with vendors, releasing the project team and updating project archives and lessons learned. Some may think that each project process group is the same as a project phase, but it s far from the truth. Actually each of the 44 processes could be performed one or more times in each phase of the project. The Closing Process Group includes all processes related to the completion of the project, including answers to the three questions related to the question "How well did you do?" These processes are as follows: Gaining client approval of having met project requirements 285

286 Planning and installing deliverables Writing the final project report Conducting the post-implementation audit The end is finally coming into sight. The client is satisfied that you have met the acceptance criteria. It's time to install the deliverables and complete the administrative closedown of the project WHAT IS A PROJECT MANAGEMENT PLAN (PMP) A project management plan is a fundamental tool for the project manger to deliver the project successfully. This document is a strategic and formalized roadmap to accomplish the project s objectives by describing how the project is to be executed, monitored and controlled, which includes creating a project work breakdown structure, identifying and planning to mitigate risk, identifying manners in which to effectively communicate with stakeholders and other project team members, and developing a plan to manage changes. It is essentially a guide for executing the project, and a manner in which to gain buy-in and approval from stakeholders and sponsors prior to commencement. This plan is a living document that is updated and revised throughout the project at strategic milestones or significant events to accommodate the progressive, elaborative nature of the project. The project management plan will vary based on size, complexity, risk, and/or sensitivity of the project. Implementing the project management plan requires competency in all of the project management knowledge areas and is critical to the success of the project PROJECT INITIATION The purpose of Project Initiation is to evaluate proposed projects and to reach a consensus on the projects to be selected. During Project Initiation, the Project Charter is presented, and the strength of a project s Business Case and the viability of the proposed solution are evaluated. A determination is made as to whether the project is consistent with the institution s business and/or strategic plan, and if the Project Planning (High Level) budget is affordable. 286

287 Project initiation phase The project initiation phase is the critical phase within the project life-cycle. It is also called the project pre-planning phase and about stating the basic characteristics of the project. To successfully initiate a project, you need to which basics steps are required to carry out to develop a business case, undertake a feasibility study, develop a project charter and others. Here are the basic steps of the project initiation phase: Step 1: Create a Business Case. A business case document is the formal start of the project when the project sponsor (or the project initiator) gives a description of the business problem/opportunity. The project is to be initiated to address the problem or provide alternative solutions. The business case document will include the business problem and potential costs associated with the project implementation. Step 2: Make a Feasibility Study. A feasibility study is a research conducted to determine whether the project can be accomplished and to identify the likelihood of the alternative solutions. The feasibility study investigates whether the benefits stated in the business case can be delivered. It also depicts relationship of business costs with the project solutions. Step 3: Develop Project Charter. Once the business problem/opportunity and possible solutions have been identified, your next step is to develop a project charter which is the critical document of the initiation phase. The project charter essentially describes what your project sets out to solve the business problem and what the boundaries of the project will be. It specifies the project vision, goals & objectives, scope & boundaries, deliverables & expectations, project organization and an implementation plan. Step 4: Assign Project Management Team. The project charter is developed so you can proceed with identifying human resources required for delivering the project and achieving its goals. You will need to appoint the management team which will take the primary responsibility for the planning and implementation of your project. The Project Committee should be established and the project manager should be assigned. Then the project manager will work on recruiting the project team and making project assignments. Once the team is recruited and assignments are made, the project initiation phase is almost finished; only one step is ahead. 287

288 Step 5: Perform Project Review. Your last step to take through the project initiation phase is about reviewing your project. A review stage should be conducted to ensure that the project is successfully initiated this means all of the initiation activities are completed. Once the project is reviewed, the project planning phase will be PROJECT PLANNING Planning is often the most difficult and unappreciated process in project management. Because planning is not always used to facilitate action, many people view planning negatively. The main purpose of project plans, however, is to guide project execution. To guide execution, plans must be realistic and useful, so a fair amount of time and effort must go into the planning process; people who are knowledgeable with the work need to plan the work. The project management knowledge areas, processes, and outputs of project planning according to the PMBOK Guide, Fifth Edition. There are many potential outputs from the planning process group, and every knowledge area is included. Just a few planning documents from JWD Consulting project management intranet site project are provided in this chapter as examples, and later chapters include many more examples. Recall that the PMBOK Guide is only a guide; so many organizations may have different planning outputs based on their particular needs, as is the case in this example. You can also use many templates for planning; several are listed in the last section of this chapter. Because the project management intranet site project is relatively small, Erica believes some of the most important planning documents to focus on are the following: A team contract A project scope statement A work breakdown structure (WBS), a key part of the scope baseline A project schedule, in the form of a Gantt chart with all dependencies and resources entered A list of prioritized risks (part of a risk register) All of these documents, as well as other project-related information, will be available to all team members on a project Web site. JWD Consulting has used project Web sites for several years, and has found that they help facilitate communications and document project information. 288

289 Soon after the project team signed the project charter, Erica organized a team-building meeting for the project management intranet site project. An important part of the meeting was helping the project team get to know each other. Erica had met and talked to each member separately, but this was the first time the project team would spend much time together. Jessie Faue worked in the Project Management Office with Erica, so they knew each other well, but Jessie was new to the company and did not know any of the other team members. Michael Chen was a senior consultant and often worked on the highest-priority projects for external clients. He attended the meeting with his assistant, Jill Anderson, who would also support the project when Michael was too busy. Everyone valued Michael s expertise, and he was extremely straightforward in dealing with people. He also knew both of the client representatives from past projects. Kevin Dodge was JWD Consulting intranet guru, who tended to focus on technical details. Cindy Dawson was also from the IT department and had experience working as a business consultant and negotiating with outside suppliers. Kim Phuong and Page Miller, the two client representatives, were excited about the project, but they were wary of sharing sensitive information about their companies. Erica had all participants introduce themselves, and then she led an icebreaking activity so everyone would be more relaxed. She asked all participants to describe their dream vacations, assuming that cost was no issue. This activity helped everyone get to know each other and show different aspects of their personalities. Erica knew that it was important to build a strong team and have everyone work well together. Erica then explained the importance of the project, again reviewing the signed project charter. She explained that an important tool to help a project team work together was to have members develop a team contract that everyone felt comfortable signing. JWD Consulting believed in using team contracts for all projects to help promote teamwork and clarify team communications. She explained the main topics covered in a team contract and showed them a team contract template. She then had the team members form two smaller groups, with one consultant, one IT department member, and one client representative in each group. These smaller groups made it easier for everyone to contribute ideas. Each group shared its ideas for what should go into the contract, and then everyone worked together to form one project team contract. Erica could see that there were different personalities on this team, but she felt they all could work together well. 289

290 Erica wanted to keep the meeting to its two-hour time limit. The next task would be to clarify the scope of the project by developing a project scope statement and WBS. She knew it took time to develop these documents, but she wanted to get a feel for what everyone thought were the main deliverables for this project, their roles in producing those deliverables, and what areas of the project scope needed clarification. She reminded everyone what their budget and schedule goals were so they would keep the goals in mind as they discussed the scope of the project. She also asked each person to provide the number of hours he or she would be available to work on this project each month for the next six months. She then had each person write answers to the following questions: 115. List one item that is most unclear to you about the scope of this project. 14. What other questions do you have or issues do you foresee about the scope of the project? 15. List what you believe to be the main deliverables for this project. 16. Which deliverables do you think you will help create or review? Erica collected everyone s inputs. She explained that she would take this information and work with Jessie to develop the first draft of the scope statement that she would to everyone by the end of the week. She also suggested that they all meet again in one week to develop the scope statement further and to start creating the WBS for the project PROJECT EXECUTION Executing the project involves taking the actions necessary to ensure that activities in the project plan are completed. It also includes work required to introduce any new hardware, software, and procedures into normal operations. The products of the project are created during project execution, and it usually takes the most resources to accomplish this process. The knowledge areas, executing processes, and outputs of project execution listed in the PMBOK Guide, Fifth Edition. Many project sponsors and customers focus on deliverables related to providing the products, services, or results desired from the project. It is also important to document change requests and prepare updates to planning documents as part of execution. For this relatively small project, Erica would work closely with all the team members to make sure they were producing the desired work results. She also used her networking skills to get input from other people in the firm and from external sources at no additional cost to the 290

291 project. She made sure that everyone who would use the resulting intranet application also understood what they were producing as part of the project and how it would help them in the future. She knew that providing strong leadership and using good communication skills were crucial to good project execution. The firm did have a formal change request form, but primarily used it for external projects. The firm also had contract specialists and templates for several procurement documents that the project team would use for the portions of the project it planned to outsource. As mentioned earlier, Erica knew that Joe, the CEO and project sponsor, liked to see progress on projects through milestone reports. He also wanted Erica to alert him to any potential issues or problems. Erica met with most of her project team members often, and she talked to Joe about once a week to review progress on completing milestones and to discuss any other project issues. Although Erica could have used project management software to create milestone reports, she used word-processing software instead because this project was small and she could more easily manipulate the report format. Human resource issues often occur during project execution, especially conflicts. At several of the team meetings, Erica could see that Michael seemed to be bored and often left the room to make phone calls to clients. She talked to Michael about the situation, and she discovered that Michael was supportive of the project, but he knew he could only spend a minimal amount of time on it. He was much more productive outside of meetings,so Erica agreed to have Michael attend a minimal number of project team meetings. She could see that Michael was contributing to the team by the feedback he provided and his leadership on the Ask the Expert feature for the intranet site. Erica adjusted her communication style to meet his specific needs. Another problem occurred when Cindy was contacting potential suppliers for software to help with the Ask the Expert and User Requests features. Kevin wanted to write all of the software for the project himself, but Cindy knew it made better business sense to purchase these new software capabilities from a reliable source. Cindy had to convince Kevin that it was worth buying some software from other sources. Cindy also discovered that their estimate of $10,000 was only about half the amount they needed for software services. She discussed the problem with Erica, explaining the need for some custom development no matter which supplier they chose. Erica agreed that they should go 291

292 with an outside source, and she asked their sponsor to approve the additional funds. Joe agreed, but he stressed the importance of still having the system pay for itself within a year. Erica also had to ask Joe for help when the project team received a low response rate to their survey and requests for user inputs. Joe sent an to all of JWD Consulting consultants describing the importance of the project. He also offered five extra vacation days to the person who provided the best examples of how they used tools and templates to manage their projects. Erica then received informative input from the consultants. Having effective communication skills and strong top management support are essential to good project execution PROJECT MONITORING AND CONTROLLING Monitoring and controlling is the process of measuring progress toward project objectives, monitoring deviation from the plan, and taking corrective action to match progress with the plan. Monitoring and controlling is done throughout the life of a project. It also involves nine of the 10 project management knowledge areas. On the project management intranet site project, there were several updates to the project management plan to reflect changes made to the project scope, schedule, and budget. Erica and other project team members took corrective action when necessary. For example, when they were not getting many responses to their survey, Erica asked Joe for help. When Cindy had trouble negotiating with a supplier, she got help from another senior consultant who had worked with that supplier in the past. Erica also had to request more funds for that part of the project. Project team members submitted a brief progress report every Friday to show work performance information. They were originally using a company template for progress reports, but Erica found that by modifying the old template, she received better information to help her team work more effectively. She wanted team members not only to report what they did but also to focus on what was going well or not going well, and why. This extra information helped team members reflect on the project s progress and identify areas in need of improvement. In addition to progress reports, an important tool for monitoring and controlling the project was using project management software. All team members submitted their actual hours worked on tasks each Friday afternoon by 4 p.m. via the firm s enterprise-wide project management software. They were using the enterprise version of Microsoft Project 2010, so they 292

293 could easily update their task information via the Web. Erica worked with Jessie to analyze the information, paying special attention to the critical path and earned value data. Erica wanted to finish the project on time, even if it meant spending more money. Joe agreed with that approach, and approved the additional funding Erica projected they would need based on the earned value projections and the need to make up a little time on critical tasks. Joe again emphasized the importance of the new system paying for itself within a year. Erica was confident that they could exceed the projected financial benefits, and she decided to begin capturing benefits as soon as the project team began testing the system. When she was not working on this project, Erica was managing JWD Consulting Project Management Office (PMO), and she could already see how the intranet site would help her staff save time and make their consultants more productive. One of her staff members wanted to move into the consulting group, and she believed the PMO could continue to provide its current services with one less person due to this new system-a benefit Erica had not considered before. Several of the firm s client contracts were based on performance and not hours billed, so she was excited to start measuring the value of the new intranet site to their consultants as well PROJECT CLOSING The closing process involves gaining stakeholder and customer acceptance of the final products and services and then bringing the project or project phase to an orderly end. It includes verifying that all of the deliverables are complete, and it often includes a final project report and presentation. Even though many IT projects are canceled before completion, it is still important to formally close any project and reflect on what can be learned to improve future projects. As philosopher George Santayana said, Those who cannot remember the past are condemned to repeat it. It is also important to plan for and execute a smooth transition of the project into The normal operations of the company. Most projects produce results that are integrated into the existing organizational structure. For example, JWD Consulting project management intranet site project will require staff to support the intranet site after it is operational. Erica included support costs of $40,000 per year for the projected three year life of the new system. She also created a transition plan as part of the final report to provide for a smooth transition of the system into the firm s operations. The plan included a list of issues that had to be resolved before the firm could 293

294 put the new intranet site into production. For example, Michael Chen would not be available to work on the intranet site after the six-month project was complete, so the team had to know who would support the Ask the Expert feature and plan some time for Michael to work with that person. During the closing processes of any project, project team members must deliver the final product, service, or result of the project, and update organizational process assets, such as project files and a lessons-learned report. If project team members procured items during the project, they must formally complete or close out all contracts. Erica and her team prepared a final report, final presentation, contract files, and lessonslearned report in closing the project. Erica reviewed the confidential, individual lessons-learned reports from each team member and wrote one summary lessons-learned report to include in the final documentation. Notice the bulleted items in the fourth question, such as the importance of having a good kick-off meeting, working together to develop a team contract, using project management software, and communicating well with the project team and sponsor. Erica also had Joe sign a client acceptance form, one of the sample templates on the new intranet site that the project team suggested all consultants use when closing their projects. The cover page included the project title, date, and team member names. Notice the inclusion of a transition plan and a plan to analyze the benefits of the system each year in the final report. Also, notice that the final report includes attachments for all the project management and product-related documents. Erica knew how important it was to provide good final documentation on projects. The project team produced a hard copy of the final documentation and an electronic copy to store on the new intranet site for other consultants to use as desired. Erica also organized a project closure luncheon for the project team right after the final project presentation. She used the luncheon to share lessons learned and celebrate a job well done! 16.8 SUMMARY In this unit, you have learnt the importance of source selection and the approach in contract administration in detail. The importance of Contract close-out have been discussed in detail KEYWORDS PMP Project Management Plan, 294

295 WBS Work Breakdown Structure, PMI Project Management Institute UNIT END EXERCISE 1. What is Project management plan? How a project initiation does take place? Explain. 2. Explain the following: a) Project planning b) Project execution 3. What are the steps in monitoring and controlling the project? Explain 4. How does closing of a project occur? Explain SUGGESTED READING 1. Information Technology Project Management Kathy Schwalbe, International Student Edition, THOMSON CourseTechnology, Software Project Management Bob Hughes and Mike Cotterell, Third Edition, Tata McGraw-Hill 3. Microsoft Office Project 2003 Bible, Elaine Marmel, Wiley Publishing Inc. 4. Basics of Software Project Management, NIIT, Prentice-Hall India, Software Project Management in Practice, Pankaj Jalote, Pearson Education, Software Project Management, A Concise Study, S.A. Kelkar, Revised Edition, Prentice HallIndia,