HRMA 40023 Project Management Instructional Materials PDF

Republic of the Philippines POLYTECHNIC UNIVERSITY OF THE PHILIPPINES Office of the Vice President for Academic Affairs College of Business Administration INSTRUCTIONAL MATERIALS FOR...

Republic of the Philippines POLYTECHNIC UNIVERSITY OF THE PHILIPPINES Office of the Vice President for Academic Affairs College of Business Administration INSTRUCTIONAL MATERIALS FOR HRMA 40023: PROJECT MANAGEMENT COMPILED BY: Asst. Prof. Jennifer D.G. Munsayac Dr. Joel M. Munsayac Assoc. Prof. Dante V. Alumno PUP A. Mabini Campus, Anonas Street, Sta. Mesa, Manila 1016 Direct Line: 335-1730 | Trunk Line: 335-1787 or 335-1777 local 000 Website: www.pup.edu.ph | Email: [email protected] THE COUNTRY’S 1st POLYTECHNICU  Table of Contents TOPIC 1 - THE CHANGING LANDSCAPE OF PROJECT MANAGEMENT........... 1 Overview.............................................................. 1 Learning Objectives.................................................... 1 Course Materials....................................................... 1 Topic 1 – The Changing Landscape of Project Management.................... 1 Executive View of Project Management....................................... 2 Global Project Management................................................ 3 Project Management Methodologies and Framework............................ 5 The Need for Effective Governance.......................................... 9 Engagement Project Management.......................................... 9 Customer Relations Management........................................... 12 Paperless Project Management............................................ 13 Project Management Maturity and Metrics.................................... 15 Project Management Benchmarking and Metrics............................... 20 Activities/ Assessments................................................. 29 TOPIC 2 - DRIVING FORCES FOR BETTER METRICS.......................... 30 Overview.............................................................. 30 Learning Objectives.................................................... 30 Course Materials....................................................... 30 Topic 2 – Driving Forces for Better Metrics................................. 30 Stakeholders Relations Management........................................ 30 Project Audits and the PMO................................................ 40 Scope Creep........................................................... 42 Project Health Checks.................................................... 50  Managing Distressed Projects.............................................. 53 Activities/ Assessments................................................. 67 TOPIC 3 - METRICS...................................................... 68 Overview.............................................................. 68 Learning Objectives.................................................... 68 Course Materials....................................................... 68 Topic 3 – Metrics...................................................... 68 Project Management Metrics............................................... 68 Activities/ Assessments................................................. 87 TOPIC 1 - THE CHANGING LANDSCAPE OF PROJECT MANAGEMENT OVERVIEW For more than 50 years project management has been in use but perhaps not on a worldwide basis. What differentiated companies that were using project management in the early years was whether or not they used project management, not how well they used it. Today, almost every company uses project management, and the differentiation is whether they are simply good at project management or whether they truly excel at project management. The difference between using project management and being good at project management is relatively small, and most companies can become good at project management in a relatively short time period, especially if they have executive-level support. A well-organized project management office (PMO) can also accelerate the maturation process. The difference, however, between being good and excelling at project management is quite large. One of the critical differences is that excellence in project management on a continuous basis requires more metrics than just time and cost. LEARNING OBJECTIVES After successful completion of this module, you should be able to: Appreciate the essence of taking up the course and the importance of possessing right attitude and behavior in the workplace Discuss and illustrate the global development in project management COURSE MATERIALS TOPIC 1 - THE CHANGING LANDSCAPE OF PROJECT MANAGEMENT Executive View of Project Management Global Project Management Project Management Methodologies and Framework The Need for Effective Governance Engagement Project Management Customer Relations Management Paperless Project Management Project Management Maturity and Metrics Project Management Benchmarking and Metrics 1 EXECUTIVE VIEW OF PROJECT MANAGEMENT Table 1.1 Executive View of Project Management Project management is no longer regarded as a part-time occupation or even a career path position. It is now viewed as a strategic competency needed for the survival of the firm. Superior project management capability can make the difference between winning and losing a contract. A project manager may desire to become certified in: Business Analyst Skills or Business Management Program Management Business Processes Managing Complex Projects Six Sigma Risk Management Some companies have certification boards, which meet frequently and discuss what certification programs would be of value for their project managers. Certification programs that require specific knowledge of company processes or company intellectual property may be internally developed and taught by the company’s own employees.  2 Executives have come to the realization that there is a return on investment in project management education. Therefore, executives are now investing heavily in customized project management training, especially in the behavioral courses. Other training programs that executives feel would be beneficial for the future include: Establishing metrics and key performance indicators (KPIs) Dashboard design Managing complex projects How to perform feasibility studies and cost–benefit analyses Business analysis Business case development How to validate and revalidate project assumptions How to establish project governance How to manage multiple stakeholders How to design and implement ―fluid‖ or adaptive enterprise project management methodologies How to develop coping skills and stress management skills GLOBAL PROJECT MANAGEMENT Every company in the world has complex projects that they would have liked to undertake but were unable to because of limitations such as: No project portfolio management function to evaluate projects A poor understanding of capacity planning A poor understanding of project prioritization A lack of tools for determining project value A lack of project management tools and software A lack of sufficient resources A lack of qualified resources A lack of support for project management education A lack of a project management methodology  A lack of knowledge in dealing with complexity A fear of failure A lack of understanding of metrics needed to track the project 3 Because not every company has the capability to manage these complex projects, they must look outside for suppliers of project management services. Companies that provide these services on a global basis consider themselves to be business solution providers and differentiate themselves from localized companies according to the elements in the Table 2.1 below. Those companies that have taken the time and effort to develop flexible project management methodologies and become solution providers are companies that are competing in the global marketplace. Although these companies may have as part of their core business the providing of products and services, they may view their future as being a global solution provider for the management of complex projects. Table 2.1 Global versus Non-global Companies For these companies, being good at project management is not enough; they must excel at project management. They must be innovative in their processes to the point that all processes and methodologies are highly fluid and easily adaptable to a particular client. They have an extensive library of tools to support the project management processes. Most of the tools were created internally with ideas discovered through captured lessons learned and best practices. 4 PROJECT MANAGEMENT METHODOLOGIES AND FRAMEWORKS Most companies today seem to recognize the need for one or more project management methodologies but either create the wrong methodologies or misuse the methodologies that have been created. Many times, companies rush into the development or purchasing of a methodology without any understanding of the need for one other than the fact that their competitors have a methodology. A methodology is a series of processes, activities, and tools that are part of a specific discipline, such as project management, and designed to accomplish a specific objective. When the products, services, or customers have similar requirements and do not require significant customization, companies develop methodologies to provide some degree of consistency in the way that projects are managed. With these methodologies, the metrics, once established, usually remain the same for every project. There are significant advantages to the design and implementation of a good, flexible methodology: Shorter project schedules Reduces and/or provides better control of costs Prevents unwanted scope changes Can plan for better execution Can predict results more accurately Improves customer relations during project execution Can adjust the project during execution to fit changing customer requirements Provides senior management with better visibility of status Provides standardization in execution Captures best practices Rather than using policies and procedures, some methodologies are constructed as a set of forms, guidelines, templates, and checklists that can and must be applied to a specific project or situation. It may not be possible to create a single enterprise-wide methodology that can be applied to each and every project. Some companies have been successful doing this, but there are still many companies that successfully maintain more than one methodology. Unless the project manager is capable of tailoring the enterprise project management methodology to his/her needs, more than one methodology may be necessary. 5 Deciding on what type of methodology is not an easy task. There are many factors to consider such as: The overall company strategies—how competitive are we as a company? The size of the project team and/or scope to be managed The priority of the project How critical the project is to the company How flexible the methodology and its components are There are numerous other factors that can influence the design of a methodology. Some of these factors include: Corporate strategy Complexity and size of the projects in the portfolio Management’s faith in project management Development budget Number of life cycle phases Technology requirements Customer requirements Training requirements and costs Supporting tools and software costs Project management methodologies are created around the project management maturity level of the company and the corporate culture. If the company is reasonably mature in project management and has a culture that fosters cooperation, effective communication, teamwork, and trust, then a highly flexible methodology can be created based upon guidelines, forms, checklists, and templates. The more flexibility that is added into the methodology, the greater the need for a family of metrics and KPIs. Project managers can pick and choose the parts of the methodology and metrics that are appropriate for a particular client. Organizations that do not possess either of these two characteristics rely heavily upon methodologies constructed with rigid policies and procedures, thus creating significant paperwork requirements with accompanying cost increases, and removing the flexibility that the project 6 manager needs to adapt the methodology to the needs of a specific client. These rigid methodologies usually rely upon time and cost as the only metrics and can make it nearly impossible to determine the real status of the project. Jason Charvat describes these two types as light methodologies and heavy methodologies: 1. Light Methodologies Lightweight projects have only a few rules, practices, and documents. Projects are designed and built on face to face discussions, meetings, and the flow of information to the clients. Light methodologies are much less documentationoriented, usually emphasizing a smaller amount of documentation for the project. 2. Heavy Methodologies Heavy methodologies attempt to plan a large part of a project in great detail over a long span of time. This works well until things start changing, and the project managers inherently try to resist change. Frameworks More and more companies today, especially those that wish to compete in the global marketplace as a business solution provider, are using frameworks rather than methodologies. A framework is a basic conceptual structure that is used to address an issue, such as a project. It includes a set of assumptions, project-specific metrics, concepts, values, and processes that provide the project manager with a means for viewing what is needed to satisfy a customer’s requirements. A framework is a skeletal support structure for building the project’s deliverables. Frameworks focus on a series of processes that must be done on all projects. Each process is supported by a series of forms, guidelines, templates, checklists, and metrics that can be applied to a particular client’s business needs. 7 Both methodologies and frameworks are mechanisms by which we can obtain best practices and lessons learned in the use of metrics and KPIs. Figure 1. Figure 3.1 Generic Methodology Figure 3.1 illustrates the generic use of a methodology or framework. Once we identify the clients and stakeholders, we then input the requirements, business case, and accompanying assumptions. The methodology then guides us through the PMBOK ® Guide process groups of initiation (I), planning (P), execution (E), monitoring and controlling (M), and closure (C). The methodology also provides us with guidance in the identification of metrics, KPIs, and dashboard reporting techniques for a particular client. Some people believe that, once the deliverables are provided to the client and project closure takes place, the project is completed. 8 However, more companies today are adding, at the end of the life cycle phases of the methodology, another life cycle phase, entitled ―Customer Satisfaction Management.‖ The purpose of this phase is to meet with the client and the stakeholders and discuss what was learned on the project regarding best practices, lessons learned, metrics, and KPIs. The intent is to see what can be done better for that client on future projects. THE NEED FOR EFFECTIVE GOVERNANCE Project governance is actually a framework by which decisions are made. Governance relates to decisions that define expectations, accountability, responsibility, the granting of power, or the verifying of performance. Governance relates to consistent management, cohesive policies, processes, and decision- making rights for a given area of responsibility. Governance enables efficient and effective decision making to take place. Every project can have different governance, even if each project uses the same enterprise project management methodology. The governance function can operate as a separate process or as part of project management leadership. Governance is not designed to replace project decision making but to prevent undesirable decisions from being made. Effective governance must be supported by a good project management information system (PMIS). The PMIS must have agreed upon metrics and key performance indicators such that informed decision making is possible rather than seat-ofthe- pants decision making. Historically, governance was provided by the project sponsor. Today, governance is provided by a committee. The membership of the committee can change from project to project and industry to industry. The membership may also vary according to the number of stakeholders and whether the project is for an internal or external client. 9 ENGAGEMENT PROJECT MANAGEMENT With project management viewed as a strategic competency today, it is natural for companies that wish to compete in a global marketplace to be strong believers in ―engagement project management‖ or ―engagement selling.‖ Years ago, the sales force would sell a product or services to a client and then move on to find another client. Today, the emphasis is on staying with the clients and looking for additional work from the same clients. In a marital context, an engagement can be viewed as the beginning of a lifelong partnership. The same holds true with engagement project management. Companies like IBM and Hewlett- Packard no longer view themselves as selling products or services. Instead, they 10 see themselves as business solution providers for their clients, and you cannot remain in business as a business solution provider without having superior project management capability. As part of engagement project management, you must convince the client that you have the project management capability to provide solutions to their business needs on a repetitive basis. In exchange for this, you want the client to treat you as a strategic partner rather than as just another contractor. This is shown in Figure 4.1. Figure 4.1 Engagement‖ Project Management Companies that wish to compete in a global environment must have superior project management capability. This capability must appear in the contractor’s response to a request for proposal issued by the client. Clients today are demanding the following in their proposal: Show us the number of Project Management Professionals (PMP) in your company and identify which PMP will manage this contract if you are the winner through competitive bidding. Show us that you have an enterprise project management methodology or framework, and that it has a history of providing repeated successes. Show us that you are willing to customize the framework or methodology to fit the client’s environment. Show us the maturity level of project management in your company and identify which project management maturity model you used to perform the assessment. Show us that you have a best practices library for project management and your willingness to share this knowledge with us, as well as the best practices you discover on our project. 11 Decades ago, the sales force (and marketing) had very little knowledge about project management. The role of the sales force was to win contracts, regardless of the concessions that had to be made. The project manager then ―inherited‖ a project with an underfunded budget and an impossible schedule. Today, sales and marketing must understand project management and be able to sell it to the client as part of engagement selling. The sales force must sell the company’s project management methodology or framework and the accompanying best practices. Sales and marketing are now involved in project management. Engagement project management benefits both the buyer and the seller, as shown in Table 4.1 below. Table 4.1 Before and after Engagement Project Management The benefits of engagement project management are clear: Both the buyer and the seller save on significant procurement costs by dealing with single-source or sole-source contracts without having to go through a formalized bidding process for each project. Because of the potential long-term strategic partnership, the seller is interested in the lifetime value of the business solution rather than just the value at the end of the project. You can provide lifelong support to your client as they try to develop value-driven relationships with their clients. 12  The buyer will get access to many of the project management tools used by the seller. The corollary is also true. There is a risk in hiring consultants to manage your projects if they bring their own methodology and accompanying metrics that are not compatible to your business or your needs. You must make sure that the business solution providers demonstrate that: Their approach is designed to your business model and strategy. The metrics they bring with them fit your business model and strategy. You understand the metrics they are proposing. If necessary, they are willing to create additional metrics that fit your needs. CUSTOMER RELATIONS MANAGEMENT Engagement project management is forcing project managers to become active participants in customer relations management (CRM) activities. CRM activities focus on: Identifying the right customers Developing the right relationship with the customers Maintaining customer retention This cannot be done entirely by the project manager. Some companies have both engagement managers and project managers. These two individuals must work together to maintain customer satisfaction. Table 5.1 below shows the partial responsibilities of each. 13  Table 5.1 Engagement Manager versus Project Manager PAPERLESS PROJECT MANAGEMENT Making informed decisions requires information. In the early years of project management, we relied heavily upon legacy systems for the information we needed. Over the past several decades, other information systems have emerged as seen in Figure 6.1 below. Figure 6.1 Growth of Information Systems to Support Project 14  Project management information systems (PMIS) evolved to provide information solely for the project at hand. Later, enterprise resource planning (ERP) systems and customer relations management (CRM) systems appeared that provided project management with sufficient information such that they could now make business as well as project based decisions. Today, the amount of information that a company can generate is overwhelming, and all of this information will be stored in data or information warehouses. With pure legacy systems that tracked business metrics the information was reported mainly vertically up the organizational hierarchy. Today, project-based information can be reported everywhere including organizations external to your company. Having more information comes with a price: more costly reporting and larger and more frequent reports. This is shown in Figure 6.2 below. As the cost of paperwork grew, companies began looking at the possibility of paperless project management. This would necessitate identification of only the critical information and presenting the information using dashboards. Figure 6.2 Growth of Information Systems to Support Project Management 15 Initially, reporting was done at the end of each life cycle phase. Unfortunately, some customers would not see project status until the end of phase gate review meetings. To solve this problem, created policy and procedure manuals are created that dictated how and when reporting should take place. Unfortunately, this placed restriction on the project managers, and eventually the policies and procedures were replaced with guidelines. Today, the focus is on dashboards. PROJECT MANAGEMENT MATURITY AND METRICS All companies desire maturity and excellence in project management. Unfortunately, not all companies recognize that the time frame can be shortened by performing strategic planning for project management maturity and excellence. The simple use of project management, even for an extended period of time, does not lead to excellence. Instead, it can result in repeated mistakes and, what’s worse, learning from your own mistakes rather than the mistakes of others. Strategic planning for project management is unlike other forms of strategic planning in that it is most often performed at the middle and lower levels of management. Executive management is still involved, mostly in a supporting role, and provides funding together with employee release time for the effort. There are models that can be used to assist in achieving excellence. One such model is the Project Management Maturity Model (PMMM), shown in Figure 7.1 below. Each of the five levels represents a different degree of maturity in project management. 16  Figure 7.1 Project Management Maturity and Metrics Level 1 Common Processes In this level, the organization recognizes the importance of project management and the need for a good understanding of the basic knowledge on project management, along with the accompanying language and terminology. Level 2 Common Processes In this level, the organization recognizes that common processes need to be defined and developed such that the successes on one project can be repeated on other projects. Also included in this level is the recognition that project management can be applied to and support other methodologies employed by the company. Level 3 Singular Methodology In this level the organization recognizes the synergistic effect of combining all corporate methodologies and processes into a singular methodology, the center of which is project 17  management. The synergistic effects also make process control easier with a single methodology than with multiple methodologies. Level 4 Benchmarking This level contains the recognition that process improvement is necessary to maintain a competitive advantage. Benchmarking should be performed on a continuous basis. The company must decide who to benchmark against and what to benchmark. Level 5 Continuous Improvement In this level, the organization evaluates the information obtained through benchmarking and must then decides whether or not this information will enhance the singular methodology. Although these five levels are normally accomplished with forms, guidelines, templates, and checklists, the growth in metrics management has allowed us to further enhance PMMM by including in each level the necessity for metrics. This is shown in Figure 7.1. Metrics can serve as a sign of organizational maturity. The need for paperless project management will require that more emphasis be placed upon metrics management as part of the project management maturity process. Maturity in project management allows companies to recognize that project management is a strategic competency as shown in Figure 7.2 below. For companies that promote their project management capabilities to external clients, competency in project management is viewed as a sustained competitive advantage (SCA). In Figure 7.2 we showed that excellence in project management is achieved when project management is seen as a strategic competency and the company recognizes that its project management capability has become a competitive advantage. 18  Figure 7.2 Project Management Competitiveness However, ineffective metrics management can increase the risks in maintaining a sustained competitive advantage as shown in Figure 7.3 below. These risks will be covered in detail in later chapters. 19  Figure 7.3 Metric Risks to Maintain a SCA Having a sustained competitive advantage in project management does not come just from being on time and on budget at the end of each project. Rather, offering your clients something that your competitors cannot do may help. But in project management, a true competitive advantage occurs when your efforts are directly linked to the customers’ perception of value, and whatever means you use to show this, such as through the use of value-reflective metrics, gives you a sustainable competitive advantage. Figure 7.4 Non-sustainable Competitive Advantages 20  Unfortunately, competitive advantages are not always sustainable as can be seen from Figure 7.4. As you exploit your competitive advantage, the competitors counterattack to reduce or eliminate your competitive advantage. Figure 7.5 Sustainable Competitive Advantages Therefore, as illustrated in Figure 7.5, you must have continuous improvement for the competitive advantage to grow into a sustained competitive advantage. 21  Table 7.1 Competitive Advantages from Value -Reflective Metrics There is no point in wasting resources on value metrics unless the client understands the metric and perceives the value that is being created. Therefore, client input into the selection of the attributes for the value metrics is essential. Table 7.1 shows some typical value-reflective metrics and the accompanying strategic competitive advantage. PROJECT MANAGEMENT BENCHMARKING AND METRICS One of the fastest ways to reach maturity and excellence in project management is through the use of benchmarking. A benchmark is a measurement or standard against which comparisons can be made. Benchmarking is the process of comparing one’s business processes and performance metrics to industry bests or best practices from other industries. Dimensions typically measured are quality, time, and cost. In the process of benchmarking, management identifies the best firms in their industry, or in another industry where similar processes exist, and compares the results and processes of those studied (the ―targets‖) to their own company’s results and processes. In this way, they learn how well the targets perform and, more importantly, the business processes that explain why these firms are successful. Best Practice versus Proven Practice In project management, the terms ―best practice benchmarking‖ or ―process benchmarking,‖ in which organizations evaluate various aspects of their processes in relation to best practice companies’ processes, usually within a peer group defined for the purposes of comparison. This then allows organizations to develop plans on how to make improvements or adapt specific best practices, usually with the aim of increasing some aspect of project management 22 performance. Benchmarking is often treated as a continuous process in which organizations continually seek to improve their practices. For more than a decade, companies have been fascinated with the expression ―best practices.‖ Best practices are generally those practices that have been proven to produce superior results. But now, after a decade or more of use, we are beginning to scrutinize the term and realize that perhaps better expressions exist. When a company says that it has a best practice, it really means that there is a technique, process, metric, method, or activity that can be more effective at delivering an outcome than any other approach and provides the company with the desired outcome with fewer problems and unforeseen complications. As a result, the company ends up with the most efficient and effective way of accomplishing a task based upon a repeatable process that has been proven over time for a large number of people and/or projects. Once a best practice has been identified and been proven to be effective, we normally integrate the best practice into our project management processes so that it becomes a standard way of doing business. Therefore, after acceptance and proven use of the idea, the better expression possibly should be a ―proven practice‖ rather than a best practice. This leaves the door open for further improvements. Benchmarking Methodologies There is no single benchmarking process that has been universally adopted. The wide appeal and acceptance of benchmarking has led to the emergence of benchmarking methodologies. The following is an example of a typical benchmarking methodology: 1. Identify problem areas Because benchmarking can be applied to any business process or function, a range of research techniques may be required. They include informal conversations with customers, employees, or suppliers; exploratory research techniques such as focus groups; and in- depth marketing research, quantitative research, surveys, questionnaires, reengineering analysis, process mapping, quality control variance reports, financial ratio analysis, or simply reviewing cycle times or other performance indicators. 23  2. Identify others that have similar processes Because project management exists in virtually every industry, benchmarking personnel should not make the mistake of looking only at their own industry. 3. Identify organizations that are leaders in these areas Look for the very best in any industry and in any country. Consult customers, suppliers, financial analysts, trade associations, and magazines to determine which companies are worthy of study. Symposiums and conferences sponsored by the Project Management Institute provide excellent opportunities to hear presentations from companies that are doing things exceptionally well. 4. Visit the ―best practice‖ companies to identify leading edge practices Companies typically agree to mutually exchange information beneficial to all parties in a benchmarking group and share the results within the group. 5. Implement new and improved business practice Take the leading edge practices and develop implementation plans that include identification of specific opportunities, funding the project, and selling the ideas to the organization for the purpose of gaining demonstrated value from the improvements. Benchmarking Costs The three main types of costs in benchmarking are: 1. Visitation costs 24  This includes hotel rooms, travel costs, meals, a token gift, and lost labor time. 2. Time costs Members of the benchmarking team will be investing time in researching problems, finding exceptional companies to study, visits, and implementation. This will take them away from their regular tasks for part of each day so additional staff might be required. 3. Benchmarking database costs Organizations that institutionalize benchmarking into their daily procedures find it is useful to create and maintain a database or library of best practices. The cost of benchmarking can substantially be reduced through utilizing the many internet resources that have sprung up over the last few years. These aim to capture benchmarks and best practices from organizations, business sectors, and countries to make the benchmarking process much quicker and cheaper. Types of Benchmarking There are several types of benchmarking studies: 1. Process benchmarking The initiating firm focuses its observation and investigation of project management and business processes with a goal of identifying and observing the best practices from one or more benchmark firms. This is the most common form of benchmarking in project management. Process benchmarking cannot be successful if you do not fully understand your own processes. 2. Metric benchmarking 25  The process of comparing the different metrics that organizations are using for continuous improvements. Time, cost, and quality are just three of the metrics that are being used. The intent is to identify the core metrics needed for project management. 3. Financial benchmarking Performing a financial analysis and comparing the results in an effort to assess your overall competitiveness and productivity. 4. Benchmarking from an investor perspective Extending the benchmarking universe to also compare to peer companies that can be considered alternative investment opportunities from the perspective of an investor. 5. Performance benchmarking Allows the initiator firm to assess their competitive position by comparing products and services with those of target firms. 6. Product benchmarking The process of designing new products or upgrades to current ones. This process can sometimes involve reverse engineering, which is taking apart competitors products to find strengths and weaknesses. 7. Strategic benchmarking This involves observing how others compete. This type is usually not industry specific, meaning it is best to look at other industries. 8. Functional benchmarking 26  A company will focus its benchmarking on a single function to improve the operation of that particular function. Complex functions such as human resources, finance and accounting, and information and communication technology are unlikely to be directly comparable in cost and efficiency terms and may need to be disaggregated into processes to make valid comparison. 9. Best-in-class benchmarking This involves studying the leading competitor or the company that best carries out a specific function. 10. Internal benchmarking A comparison of a business process to a similar process inside the organization. This is a quest for internal best practices. 11. Competitive benchmarking This is a direct competitor-to-competitor comparison of a product, service, process or method. 12. Generic benchmarking This approach broadly conceptualizes unrelated business processes or functions that can be practiced in the same or similar ways regardless of industry. Benchmarking Code-of-Conduct There are numerous problems that can occur during benchmarking. Some problems result from misunderstandings, whereas other problems could involve legal issues. 27 1. Legality Avoid any discussions that could be interpreted as illegal for you or your benchmarking partners. 2. Exchange Be prepared to answer the same questions you are asking. Letting partners review the questions in advance is helpful. 3. Confidentiality All information should be treated as proprietary information. You may wish to consider having everyone sign a nondisclosure agreement. 4. Use of Information There must be an agreement, preferably in writing, on how the information will be used. 5. Contact Follow your partners’ protocols and customs on who you are allowed to interface with. 28  6. Preparation Be fully prepared for partner interfacing and exchanges of information. 7. Completion Avoid making promises or commitments that cannot be kept. Benchmarking Failures There are benchmarking mistakes that can lead to benchmarking failures. Some of these mistakes include: Limiting benchmarking activities to just your own industry Benchmarking industry followers can provide just as much information as benchmarking industry leaders. Not all results may be applicable to your company, especially if organizational cultural differences exist. Failing to have a benchmarking plan and not knowing what you are looking for Points to Remember There are some critical points that must be remembered when performing benchmarking: It is necessary to understand the culture and circumstances behind the numbers to fully understand their meaning and use. The ―how‖ is just as important as the ―how much?‖ In project management, changes can occur quickly. It is important to set frequencies for the benchmarking studies, and each process studied may require different frequencies. The more rigorous the benchmarking process, the better the results. Regardless of how good you think your project management systems are, there is always room for improvement. 29  Those who do not believe in continuous improvement soon become industry followers rather than leaders. Recognize that executives who are not familiar or supportive of benchmarking will always adopt the ―not invented here‖ argument or ―this is the way we have always done it.‖ Successful benchmarking is ―doing,‖ not ―knowing.‖ Benchmarking allows you to learn from the mistakes of others rather than from your own mistakes. Because of the rate of change that takes place in project management, it is highly unlikely that the targets you benchmark with will be leaders in all areas of project management. Benchmarking can prevent surprises. You must get these people to recognize the need for change. This must be accomplished with benchmarking evidence rather than just claims or opinions. Change occurs quickly when the people who are needed to change or make the change are involved in the benchmarking studies. Implementing change requires a champion. Having a PMO is almost always the right idea. 30 31 32 33 ACTIVITIES/ ASSESSMENTS 1. How did project management evolve? 2. Discuss how customer relations management works. 3. Analyze the significance of effective governance in project management. TOPIC 2 - DRIVING FORCES FOR BETTER METRICS OVERVIEW Companies do not simply add more metrics or key performance indicators by choice. Usually, there are driving forces that make it evident that such changes are needed. Complacency works when things are going well or as planned. By performing audits and health checks, we can certainly prevent a project from becoming distressed, provided that the cause of the problem was detected early enough. Unfortunately, the existing metrics that we use might not act as an early warning system. By the time we establish new metrics for analysis of a potentially failing project, the damage may have been done and recovery may no longer be possible. The final result can be devastating if stakeholder relations management fails and future business is not forthcoming. All of this may be attributed to improper identification, selection, implementation, and measurement of the right metrics and key performance indicators. 34 LEARNING OBJECTIVES After successful completion of this module, you should be able to: Discuss the driving forces to improve the project management through metrics COURSE MATERIALS TOPIC 2 - DRIVING FORCES FOR BETTER METRICS Stakeholders Relations Management Project Audits and the PMO Scope Creep Project Health Checks Managing Distressed Projects STAKEHOLDER RELATIONS MANAGEMENT Stakeholders are individuals, companies, or organizations that may be affected by the outcome of the project or the way in which the project is managed. Stakeholders may be either directly or indirectly involved throughout the project, or may function simply as observers. A stakeholder can shift from a passive role to being an active member of the team and participate in making critical decisions. 35 On small or traditional projects, project managers generally interface with just the project sponsor as the primary stakeholder, and the sponsor usually is assigned from the organization that funds the project. This is true for both internal and external projects. However, the larger the project, the greater the number of stakeholders you must interface with. The situation becomes even more potentially problematic if you have a large number of stakeholders, geographically dispersed, all at different levels of management in their respective hierarchy, each with a different level of authority, and language and cultural differences. One of the complexities of stakeholder relations management is figuring out how to do all of this without sacrificing your company’s long-term mission or vision. Also, your company may have long-term objectives in mind for this project, and those objectives may not necessarily be aligned to the project’s objectives or each stakeholder’s objectives. Stakeholder relations management cannot work effectively without commitments from all of the stakeholders. Obtaining these commitments can be difficult if the stakeholders cannot see what’s in it for them at the completion of the project, namely the value that they expect or other personal interest. The problem is that what one stakeholder perceives as value, another stakeholder may have a completely different perception or a desire for a different form of value. Another form of agreement involves developing a consensus on how stakeholders will interact with each other. It may be necessary for certain stakeholders to interact with each other and support one another with regard to sharing resources, providing financial support in a timely manner, and sharing intellectual property. While all stakeholders recognize the necessity for these agreements, they can be affected by politics, economic conditions, and other enterprise environmental factors that may be beyond the control of the project manager. Certain countries may not be willing to work with other countries because of culture, religion, views on human rights, and other such factors. For the project manager, obtaining these agreements right at the beginning of the project is essential. Some project managers are fortunate to be able to do this while others are not. Leadership changes in certain governments may make it difficult to enforce these agreements on complex projects. It is important that everyone who has a stake in the project be willing to communicate what they believe is the factors critical for success. Success is easier to define and reach when there is 36 broad agreement. However, there is no guarantee that there will be an agreement between the project manager, client(s) and stakeholders as to a core set of metrics and KPIs. Project managers must be prepared to construct a different set of dashboards possibly for each viewer. But there is a risk. If too many metrics are established, then too much data may be necessary and the project team may find it difficult to capture all of the information that is needed. The metrics selected must be scaled to fit the needs of the project. Also, the metrics selected must be used to ensure that the time and cost involved with selecting and measuring the metrics has been worthwhile. There are some simple steps that can be followed: The project team must brainstorm what metrics are appropriate for this project. This is easy to do if a metrics library exists. This may be accomplished prior to stakeholder involvement. The team must then assess the metrics to make sure they are needed and look for ways of combining metrics if appropriate. The team must make sure that the metrics are presented in terms that every viewer can understand. (i.e., What is the meaning of a partial or incomplete deliverable? What is the meaning of an unacceptable deliverable?) The team must then decide what metrics they will recommend to the stakeholders. Sometimes, we select the number of metrics based upon the personal whims of the stakeholders and the project team and then discover how costly it is to measure and report all of the metrics. The number of metrics selected should be based upon the size of the project, the complexity, the decisions that the governance committee must make, and the accompanying risks. It is important for the project manager to fully understand the issues and challenges facing each of the stakeholders, especially their information needs. Although it may seem unrealistic, some stakeholders can have different views on the time requirements of the project. Not all stakeholders understand project management. Not all stakeholders understand the role of a project sponsor. Not all stakeholders understand how to interface with a project or the project manager, even though they may readily accept and support the project and its mission. Simply 37 stated, the majority of the stakeholders are never trained in how to properly function as a stakeholder. Unfortunately, this cannot be detected early on but may become apparent as the project progresses. Some stakeholders may be under the impression that they are merely observers and need not participate in decision making or authorization of scope changes. Some stakeholders view their role as that of micromanagers, often usurping the authority of the project manager by making decisions that they may not necessarily be authorized to make, at least not alone. It may be a good idea for the project manager to prepare a list of expectations that he/she has of the stakeholders. This is essential even though the stakeholders visibly support the existence of the project. Role clarification for stakeholders should be accomplished early on the same way that the project manager provides role clarification for the team members at the initial kickoff meeting for the project. Table 8.1 Changing Views in Stakeholder Relations Management The present view of stakeholder management in Table 8.1 results from the implementation of ―engagement project management‖ practices. In the past, whenever a sale was made to the client, the salesperson would then move on to find a new client. Salespeople viewed themselves as providers of products and/or services. Today, salespeople view themselves as the providers of business solutions. In other words, salespeople now tell the client, ―we can provide you with a solution to all of your business needs 38 and what we want in exchange is to be treated as a strategic business partner.‖ This benefits both the buyer and seller, as discussed previously. Therefore, as a solution provider, the project manager focuses heavily on the future and establishing a long-term partnership agreement with the client and the stakeholders. This focus is heavily oriented toward value rather than near-term profitability. Figure 8.1 Stakeholder Relations Management On the micro-level, we can define stakeholder relations management using the six processes shown in Figure 8.1. 1. Identify the stakeholders This step may require support from the project sponsor, sales, and the executive management team. Even then, there is no guarantee that all of the stakeholders will be identified. 39 2. Stakeholder analysis This requires an understanding of which stakeholders are key stakeholders, those who have influence, the ability and authority to make decisions, and can make or break the project. This also includes developing stakeholder relations management strategies, based upon the results of the analysis. 3. Perform stakeholder engagements During this step, the project manager and the project team get to know the stakeholders. 4. Stakeholder information flow This step is the identification of the information flow network and the preparation of the necessary reports for each stakeholder. 5. Abide by agreements This step enforces stakeholder agreements made during the initiation and planning stages of the project. 6. Stakeholder debriefings This step occurs after contract or life cycle phase closure and is used to capture lessons learned and best practices for improvements on the next project involving these stakeholders or the next life cycle phase. 40 Stakeholder management begins with stakeholder identification. This is easier said than done, especially if the project is multinational. Stakeholders can exist at any level of management. Corporate stakeholders are often easier to identify than political or government stakeholders. Each stakeholder is an essential piece of the project puzzle. Stakeholders must work together and usually interact with the project through the governance process. Therefore, it is essential to know which stakeholders will participate in governance and which will not. As part of stakeholder identification, the project manager must know whether he/she has the authority or perceived status to interface with the stakeholders. Some stakeholders perceive themselves as higher stature than the project manager and, in this case, the project sponsor may be the person to maintain interactions. There are several ways in which stakeholders can be identified. More than one way can be used on projects. Groups This could include financial institutions, creditors, regulatory agencies, and the like. Individuals These could be identified by name or title, such as the CIO, COO, CEO or just the name of the contact person in the stakeholder’s organization. Contribution This could include financial contributor, resource contributor, or technology contributor. Other factors This could include the authority to make decisions or other such factors. 41 It is important to understand that not all stakeholders have the same expectations of a project. Some stakeholders may want the project to succeed at any cost, whereas other stakeholders may prefer to see the project fail even though they openly seem to support it. Some stakeholders view success as the completion of the project regardless of the cost overruns, whereas others may define success in financial terms only. Some stakeholders are heavily oriented toward the value they expect to see in the project, and this is the only definition of success for them. On large, complex projects with a multitude of stakeholders, it may be impossible for the project manager to properly cater to all of the stakeholders. Therefore, the project manager must know who the most influential stakeholders are and who can provide the greatest support on the project. Typical questions to ask include: Who are powerful and who are not? Who will have or require direct, or indirect, involvement? Who has the power to kill the project? What is the urgency of the deliverables? Who may require more or less information than others? Not all stakeholders are equal in influence, power, or the authority to make decisions in a timely manner. It is imperative for the project manager to know who sits on the top of the list as having these capabilities. Finally, it is important to remember that stakeholders can change over the life of a project, especially if it is a long-term project. Also, the importance of certain stakeholders can change over the life of a project and in each life cycle phase. The stakeholder list is, therefore, an organic document subject to change. 42  Figure 8.2 Stakeholder Mapping Stakeholder mapping is most frequently displayed on a grid, comparing stakeholders’ power and their level of interest. This is shown in Figure 8.2. The four cells can be defined as: 1. Manage closely These are high-powered, interested people who can make or break your project. You must put forth the greatest effort to satisfy them. Be aware that there are factors that can cause them to change quadrants rapidly. 2. Keep satisfied These are high-powered, less interested people who can also make or break your project. You must put forth some effort to satisfy them but not with excessive detail that can lead to boredom and total disinterest. They may not get involved until the end of the project approaches. 43  3. Keep informed These are people with limited power but keen interest in the project. They can function as an early warning system of approaching problems and may be technically astute and able to assist with some technical issues. These are the stakeholders who often provide hidden opportunities. 4. Monitor only These are people with limited power and may not be interested in the project unless a disaster occurs. Provide them with some information but not with too much detail so that they will become disinterested or bored. The larger the project, the more important it becomes to know who is and is not an influential or key stakeholder. Although you must win the support of all stakeholders, or at least try to do so, the key stakeholders come first. Key stakeholders may be able to provide the project manager with assistance with the identification of enterprise environmental factors that can have an impact on the project. On longer-term projects, stakeholders may change over time, perhaps because of politics, promotions, retirements, or reassignments. The new stakeholder may suddenly want to be an important stakeholder, whereas his/her predecessor was more of an observer. Finally, stakeholders may be relatively quiet in one life cycle phase because of limited involvement but become more active in other life cycle phase, where they must participate. The project team must know who the stakeholders are, determine which stakeholders are critical stakeholders at specific points in time. The criticality of the stakeholder determines what metrics will appear on the stakeholder’s dashboard. Stakeholder engagement is the point when you physically meet with the stakeholders and determine their needs and expectations. As part of this, you must: Understand them and their expectations Understand their needs 44  Value their opinions Find ways to win their support on a continuous basis Identify any stakeholder problems early-on that can influence the project Even though stakeholder engagement follows stakeholder identification, it is often through stakeholder engagement that we determine which stakeholders are supporters, advocates, neutral, or opponents. This may also be viewed as the first step in building a trusting relationship between the project manager and the stakeholders. As part of stakeholder engagement, it is necessary for the project manager to understand each stakeholder’s interests. One of the ways to accomplish this is to ask the stakeholders (usually the key stakeholders) what information they would like to see in performance reports. This information will help identify the key performance indicators (KPI) needed to service that stakeholder. Part of the process of stakeholder engagement involves the establishment of agreements between the individual stakeholders and the project manager, and among other stakeholders as well. These agreements must be enforced throughout the project. The project manager must: Identify any and all agreements among stakeholders (i.e., funding limitations, sharing of information, approval cycle for changes, etc.) Identify how politics may change stakeholder agreements Identify which stakeholders may be replaced during the project (i.e., retirement, promotion, change of assignment, politics, etc.) Metrics have to be measureable, but some metric information may be difficult to quantify. For example, customer satisfaction, goodwill, and reputation may be important to some stakeholders, but they may be difficult to quantify. Some metric data may need to be measured in qualitative terms rather than quantitative terms. The need for effective stakeholder communications is clear. This includes: Communicating with stakeholders on a regular basis is a necessity. Knowing the stakeholders may allow you to anticipate their actions. Effective stakeholder communications builds trust. 45  Virtual teams thrive on effective stakeholder communications. Although we classify stakeholders by groups or organizations, we still communicate with people. Ineffective stakeholder communications can cause a supporter to become a blocker. Sometimes, regardless of how hard we try, we will fail at stakeholder relations management. Typical reasons include: Inviting stakeholders to participate too early, thus encouraging scope changes and costly delays Inviting stakeholders to participate too late so that their views cannot be considered without costly delays Inviting the wrong stakeholders to participate in critical decisions, thus leading to unnecessary changes and criticism by key stakeholders Key stakeholders becoming disinterested in the project Key stakeholders who are impatient with the lack of progress Allowing the key stakeholders to believe that their contributions are meaningless Managing the project with an unethical leadership style or interfacing with the stakeholders in an unethical manner PROJECT AUDITS AND THE PMO In recent years, the necessity for a structured independent review of various parts of a business, including projects, has taken on a more important role. These independent reviews are audits that focus on either discovery or decision making. They also can focus on determining the health of a project. The audits can be scheduled or random and can be performed by in-house personnel or external examiners. There are several types of audits. Some common types include: 46 1. Performance Audits These audits are used to appraise the progress and performance of a given project. The project manager, project sponsor, or an executive steering committee can conduct this audit. 2. Compliance Audits These audits are usually performed by the project management office (PMO) to validate that the project is using the project management methodology properly. Usually the PMO has the authority to perform the audit but may not have the authority to enforce compliance. 3. Quality Audits These audits ensure that the planned project quality is being met and that all laws and regulations are being followed. The quality assurance group performs this audit. 4. Exit Audits These audits are usually for projects that are in trouble and may need to be terminated. Personnel external to the project, such as an exit champion or an executive steering committee, conduct the audits. 5. Best Practices Audits These audits can be conducted at the end of each life cycle phase or at the end of the project. Some companies have found that project managers may not be the best individuals to perform the audit. In such situations, the company may have professional facilitators trained in conducting best practices reviews. 6. Metric and KPI Audits 47  These audits are similar to Best Practices Audits and used to establish a library for metrics. SCOPE CREEP Scope creep is the continuous enhancement of the project’s requirements as the project’s deliverables are being developed. Scope creep is viewed as the growth in the project’s scope. Although scope creep can occur in any project in any industry, it is most frequently associated with information systems development projects. Scope changes can occur during any project life cycle phase. This is particularly true on large, complex projects. As a result, we gain more knowledge as the project progresses, and this leads to creeping scope and scope changes. Scope creep is a natural occurrence for project managers. We must accept the fact that this will happen. Perhaps the best we can do is to establish processes, such as configuration management systems or change control boards, to get some control over scope creep. However, these processes are not designed to prevent scope creep but more to prevent unwanted scope changes from taking place. Scope creep is often viewed as being detrimental to the success of a project because it increases the cost and elongates the schedule. While this is true, scope creep can also produce favorable results such as add-ons that give your product a competitive advantage. Scope creep can also please the customer if the scope changes are seen as providing additional value for the final deliverable. Defining Scope Creep Perhaps the most critical step in the initiation phase of a project is the defining of the scope. The first attempt at scope definition may occur as early as the proposal or competitive bidding stage. Once the project manager is brought on board, he/she must either become familiar with and validate the scope requirements if they have already been prepared, or interview the various stakeholders and gather the necessary information for a clear understanding of the scope. In doing so, the project manager prepares a list of what is included and excluded from his/her understanding of the requirements. 48 Yet no matter how meticulously the project manager attempts to do this, the scope is never known with 100 percent clarity. This is one of the primary reasons why metrics may need to change over the life of the project. The project manager’s goal is to establish the boundaries of the scope. To do this, the project manager’s vision of the project and each stakeholder’s vision of the project must be aligned. There must also be an alignment with corporate business objectives because there must be a valid business reason for undertaking this project Figure 9.1 Project Boundaries Figure 9.1 shows the boundaries of the project. The project’s overall boundary is designed to satisfy both business objectives established by your company and technical/scope objectives established by your customer, assuming it is an external client. The project manager and the various stakeholders, including the customer, can have different interpretations of the scope boundary and the business boundary. Also, the project manager may focus heavily on the technology that the customer needs rather than business value that the project manager’s company desires. Simply stated, the project manager may seek to exceed the specifications, whereas the stakeholders and your company want to meet the minimum specification levels in the shortest amount of time. 49 When scope creep occurs and scope changes are necessary, the scope boundary can move. However, the scope boundary may not be able to move if it alters the business boundary and corporate expectations. As an example, a scope change to add value to a product might not be approved if it extends the launch date of the product. It is important to understand that the scope of the project is not what the customer asked for, but what we agree to deliver. What we agree to can have inclusions and exclusions from what the customer asked for. The scope boundary can drift during the implementation of the project because, as we get further into the project and more knowledge is gained, we identify unplanned additions to the scope. This scope creep phenomenon is then accompanied by cost increases and schedule elongations. The length of the project also has an impact on scope creep. If the business environment is highly dynamic and continuously changing, products and services must be developed to satisfy market needs. Therefore, on long-term projects, scope creep may be seen as a necessity for keeping up with customer demands, and project add-ons may be required to obtain customer acceptance. Scope Creep Dependencies Often, scope changes are approved without evaluating the downstream impact that the scope change can have on work packages that have not started yet. As an example, making a scope change early on in the project to change the design of a component may result in a significant cost overrun if long-lead raw materials that were ordered and paid for are no longer needed. Causes of Scope Creep In order to prevent scope creep from occurring, one must begin by understanding the causes of scope creep. The causes are numerous, and it is wishful thinking to believe that all of these causes can be prevented. Many of the causes are well beyond the control of the project manager, even though for some of these we can establish metrics that function as an early warning sign. Some causes are related to business scope creep, and others are part of technical scope creep. 50 Poor understanding of requirements This occurs when we accept or rush into a project without fully understanding what must be done. Poorly defined requirements Sometimes the requirements are so poorly defined that we must make numerous assumptions, and as we get into the later stages of the project, we discover that some of the assumptions are no longer valid. Complexity The more complex the project, the greater the impact of scope creep. Being too ambitious and believing that we can deliver more than we can offer on a complex project can be disastrous. Failing to ―drill down‖ When a project is initiated using only high-level requirements, scope creep can be expected when we get involved in the detailed activities in the work breakdown structure. Poor communications Poor communication between the project manager and the stakeholders can lead to ill-defined requirements and misinterpretation of the scope. Misunderstanding expectations 51 Regardless of how the scope is defined, stakeholders and customers have expectations of the outcome of the project. Failure to understand these expectations up front can lead to costly downstream changes. Futurities This is also called gold-plating a project and occurs when the project team adds in their own often unnecessary features and functionality in the form of ―bells and whistles.‖ Perfectionism This occurs when the project team initiates scope changes in order to exceed the specifications and requirements rather than just meeting them. Project teams may see this as a chance for glory. Career advancement Scope creep may require additional resources, perhaps making the project manager more powerful in the eyes of senior management. Scope creep also elongates projects and provides team members with a much longer tenure in a temporary home if they are unsure about their next assignment. Time-to-market pressure Many projects start out with highly optimistic expectations. If the business exerts pressure on the project manager to commit to an unrealistic product launch date, then the project manager may need to reduce functionality. Deception Sometimes we know well in advance that the customer’s statement of work has ―holes‖ in it. Rather than inform the customer about the additional work that will be 52  required, we underbid the job based upon the original scope, and after contract award, we push through profitable scope changes. Penalty clauses Some contracts have penalty clauses for late delivery. By pushing through (perhaps unnecessary) scope changes that will elongate the schedule, the project manager may be able to avoid penalty clauses. Placating the customer Some customers will request ―nice to have but not necessary‖ scope changes after the contract begins. While it may appear nice to placate the customer, always saying ―yes‖ does not guarantee follow-on work. Poor change control: The purpose of a change control process is to prevent unnecessary changes. If the change control process is merely a rubber stamp that approves all of the project manager’s requests, then continuous scope creep will occur. The Need for Business Knowledge Scope changes must be properly targeted prior to approval and implementation, and this is the weakest link because it requires business knowledge as well as technical knowledge. As an example, scope changes should not be implemented at the expense of risking exposure to product liability lawsuits or safety issues. Likewise, making scope changes exclusively for the sake of enhancing one’s image or reputation should be avoided if it could result in an unhappy client. 53 Scope changes should be based upon a solid business foundation. For example, developing a very high-quality product may seem nice at the time, but there must be customers willing to pay the higher price. The result might be a product that nobody wants or can afford. There must exist a valid business purpose for a scope change. This includes the following factors at a minimum: An assessment of the customers’ needs and the added value that the scope change will provide An assessment of the market needs, including the time required to make the scope change, the payback period, return on investment, and whether the final product’s selling price will be overpriced for the market. An assessment of the impact on the length of the project and product life cycle An assessment on the competition ’s ability to imitate the scope change An assessment on product liability associated with the scope change and the impact on the company’s image Ways to Minimize Scope Creep Some people believe that scope creep should be prevented at all costs. However, not allowing necessary scope creep to occur can be dangerous and possibly detrimental to business objectives. Furthermore, it may be impossible to prevent scope creep. Perhaps the best we can do is to control scope creep by minimizing the amount and extent of it. Some of the activities that may be helpful include: Realize that scope creep will happen 54  Scope creep is almost impossible to prevent. Rather, attempts should be made to control scope creep. Know the requirements You must fully understand the requirements of the project, and you must communicate with the stakeholders to make sure you both have the same understanding. Know the client’s expectations Your client and the stakeholders can have expectations that may not be in alignment with your interpretation of the requirements on scope. You must understand the expectations, and continuous communication is essential. Eliminate the notion that the customer is always right: Constantly saying ―yes‖ to placate the customer can cause sufficient scope creep that a good project becomes a distressed project. Some changes could probably be clustered together and accomplished later as an enhancement project. Act as the devil's advocate: Do not take for granted that all change requests are necessary even if they are internally generated by the project team. Question the necessity for the change. Make sure that there is sufficient justification for the change. Determine the effect of the change Scope creep will affect the schedule, cost, scope/requirements, and resources. See whether some of the milestone dates can or cannot be moved. Some dates are hard to move, whereas others are easy. See if additional resources are needed to perform the scope change and if the resources will be available. 55  Get user involvement early Early user involvement may prevent some scope creep or at least identify the scope changes early enough such that the effects of the changes are minimal. Add in flexibility It may be possible to add some flexibility into the budget and schedule if a large amount of scope creep is expected. This could appear as a management/contingency monetary reserve for cost issues and a ―reserve‖ activity built into the project schedule for timing issues. Know who has signature authority Not all members of the scope change control board possess signature authority to approve a scope change. You must know who possesses this authority. In general, people who request scope changes do not do so in an attempt to make your life miserable. They do so because of a desire to ―please,‖ through a need for perfection, to add functionality, or to increase the value in the eyes of the client. Some scope changes are necessary for business reasons, such as add-ons for increased competitiveness. Scope creep is a necessity and cannot be eliminated, but it can be controlled. 56 PROJECT HEALTH CHECKS Projects seem to progress quickly until they are about 60%–70% complete. During that time, everyone applauds that work is progressing as planned. Then, perhaps without warning, the truth comes out and we discover that the project is in trouble. This occurs because of: Our disbelief in the value of using project’s metrics Selecting the wrong metrics Our fear of what project health checks may reveal Most projects seem to focus on only two metrics: time and cost. These are the primary metrics in all earned value measurement systems (EVMS). While these two metrics ―may‖ give you a reasonable representation of where you are today, using these two metrics to provide forecasts into the future and may not indicate future problem areas that could prevent a successful and timely completion of the project. Rather than relying on metrics alone, the simplest solution might be to perform periodic health checks on the project. In doing this, three critical questions must be addressed: Who will perform the health check? Will the interviewees be honest in their responses? Will management and stakeholders overreact to the truth? The surfacing of previously unknown or hidden issues could lead to loss of employment, demotions, or project cancellation. Yet project health checks offer the greatest opportunity for early corrective action to save a potentially failing project. Health checks can also discover future opportunities. It is essential to use the right metrics. Understanding Project Health Checks Health checks can function as an ongoing tool, being performed randomly when needed or periodically throughout various life cycle stages. However, there are specific circumstances that indicate that a health check should be accomplished quickly. These include: 57  Significant scope creep Escalating costs accompanied by deterioration in value and benefits schedule slippages that cannot be corrected Missed deadlines Poor morale accompanied by changes in key project personnel Metric measurements that fall below the threshold levels Periodic health checks, if done correctly and using good metrics, eliminate ambiguity so that the true status can be determined. The benefits of health checks include: Determining the current status of the project Identifying problems early enough that sufficient time exists to take corrective action Identifying the critical success factors that will support a successful outcome or the critical issues that can prevent successful delivery Identifying lessons learned, best practices, and critical success factors that can be used on future projects Evaluating compliance with and improvements to the enterprise project management methodology Validate that the project ’s metrics are correct and provide meaningful data Identifying which activities may require or benefit from additional resources Identifying present and future risks as well as possible risk mitigation strategies Determining if the benefits and value will be there at completion Determining if euthanasia is required to put the project out of its misery The development of or recommendations for a fix-it plan There are misconceptions about project health checks. Some of these are: The person doing the health check does not understand the project or the corporate culture, and is, thus, wasting time. The health check is too costly for the value we will get by performing it. The health check ties up critical resources in interviews. 58  By the time we get the results from the health check, either it will be too late to make changes or the nature of the project may have changed. Who Performs the Health Check? One of the challenges facing companies is whether the health check should be conducted by internal personnel or by external consultants. The risk with using internal personnel is that they may have loyalties or relationships with people on the project team and, therefore, may not be totally honest in determining the true status of the project or in deciding who was at fault. Using external consultants or facilitators is often the better choice. External facilitators can bring to the table: A multitude of forms, guidelines, templates, and checklists used in other companies and similar projects A promise of impartiality and confidentiality A focus on only the facts and hopefully free of politics An environment where people can speak freely and vent their personal feelings An environment that is relatively free from other day-to-day issues New ideas for project metrics Life Cycle Phases There are three life cycle phases for project health checks. These include: Review of the business case and the project’s history Reviewing the business case and project’s history may require the health check leader to have access to proprietary knowledge and financial information. The leader may have to sign nondisclosure agreements and also non-compete clauses before being allowed to perform the health check. 59 Research and discovery of the facts In the research and discovery phase, the leader prepares a list of questions that need to be answered. The questions come from the knowledge repository in the consultant’s company and may also come from business case analysis templates, guidelines, checklists, or forms. 60  The questions can change from project to project and industry to industry. Some of the critical areas that must be investigated include: Performance against baselines Ability to meet forecasts Benefits and value analyses Governance Stakeholder involvement Risk mitigation Contingency planning Preparation of the health check report The final phase is the preparation of the report. This should include: A listing of the issues Root cause analyses, possibly including identification of the individuals who created the problems Gap analysis Opportunities for corrective action A get-well or fix-it plan Project health checks are part of project oversight. Without these health checks, the chances for project failure significantly increase. Project health checks also provide us with insight on how to keep risks under control. Performing health checks and taking corrective action early is certainly better than having to manage a distressed project. MANAGING DISTRESSED PROJECTS When a project failure occurs in professional sports, managers and coaches are fired, there is a shakeup in executive leadership. Tactics are used to recover failing projects in industry. There are some general facts about troubled projects: Some projects are doomed to fail regardless of recovery attempts. The chances of failure on any given project may be greater than the chances of success. 61  Failure can occur in any life cycle phase; success occurs at the end of the project. Troubled projects do not go from ―green‖ to ―red‖ overnight. There are early warning signs, but they are often overlooked or misunderstood. Most companies have a poor understanding of how to manage troubled projects. Not all project managers possess the skills to manage a troubled project. Not all projects will be successful. Companies that have a very high degree of project success probably are not working on enough projects and certainly are not taking on very much risk. These types of companies eventually become followers rather than leaders. For companies that desire to be leaders, knowledge on how to turn around a failing or troubled project is essential. Projects do not get into trouble overnight. There are early warning signs, but most companies seem to overlook them or misunderstand them. Failure to recognize these signs early can make the downstream corrections a very costly endeavor. Also, the longer you wait to make the corrections, the more costly the changes become. Some companies perform periodic project health checks. These health checks, when applied to healthy looking projects, can lead to the discovery that the project may be in trouble even though on the surface the project looks healthy. Outside consultants are often hired for the health checks in order to get an impartial assessment. When a project gets way off track, the cost of recovery is huge, and vast or even new resources may be required for corrections. The ultimate goal for recovery is no longer to finish on time, but to finish with reasonable benefits and value for the customer and the stakeholders. The project’s requirements may change during recovery to meet the new goals if they have changed. Regardless of what you do, however, not all troubled projects can be recovered. ―Root‖ Causes of Failure There are numerous causes of project failure. Some causes are quite common in specific industries, such as information technology, whereas others can appear across all industries. Here is a generic list of common causes of failure: Poor estimates, especially financial 62  Unclear stakeholder requirements Unclear expectations Assumptions, if they exist at all, are unrealistic Plans are based upon insufficient data No systemization of the planning process Inadequate or incomplete requirements Lack of resources Assigned resources lack experience Staffing requirements are not fully known Constantly changing resources Poor overall project planning Team members working with conflicting requirements Poor or fragmented cost control Weak project and stakeholder communications Poor assessment of risks if done at all Poor project management; team members possess a poor understanding of project management, especially virtual team members. These causes of project failure can be sorted into three broad categories. 1. Management mistakes These are the result of a failure in stakeholder management perhaps by allowing too many unnecessary scope changes, failing to provide proper governance, refusing to make decisions in a timely manner, and not performing project health checks. 2. Planning mistakes These are the result of poor project management, not having a timely ―kill switch‖ in the plan, not planning for project audits or health checks, and not selecting the proper tracking metrics. 63  3. External influences These are normally failures in assessing the environmental input factors correctly. This includes the timing for getting approvals and authorization from third parties, and a poor understanding of the host country’s culture and politics. The Definition of Failure The project manager and the stakeholders can have different definitions of project failure. The project manager’s definition might just be not meeting the competing constraints criteria. Stakeholders, on the other hand, might seem more interested in business value than the competing constraints once the project actually begins. Stakeholders’ perception of failure might be: The project has become too costly for the expected benefits or value The project will be completed too late The project will not achieve its targeted benefits or value The project no longer satisfies the stakeholders’ needs Early Warning Signs of Trouble Projects do not become distressed overnight. They normally go from ―green‖ to ―yellow‖ to ―red,‖ and along the way are early warning signs or metrics indicating that failure may be imminent or that immediate changes may be necessary. Typical early warning signs include: Business case deterioration Different opinions on project’s purpose and objectives Continuous criticism by stakeholders Changes in stakeholders without any warning No longer a demand for the deliverables or the product Invisible sponsorship Delayed decisions resulting in missed deadlines High-tension meetings with team and stakeholders Finger-pointing and poor acceptance of responsibility Failing to close life cycle phases properly 64  Unrealistic expectations Failure in progress reporting Technical failure Unclear milestones and other requirements Poor morale Poor change control process. The earlier the warning signs are discovered, the more opportunities exist for recovery. This is the time when a project health check should be conducted. Successful identification and evaluation of the early warning signs can tell us that the distressed project: Can succeed according to the original requirements, but some minor changes are needed Can be repaired, but major changes may be necessary Cannot succeed and should be killed There are three possible outcomes when managing a troubled project: The project must be completed; that is, it is required by law The project can be completed, but with major costly changes to the requirements The project should be canceled Costs and benefits are no longer aligned What was once a good idea no longer has merit Some projects cannot be canceled because they are required by law. These include those necessary for compliance with government laws on e