Managing Projects

The starting point in discussing how projects should be properly managed is to first understand what a project is and, just as importantly, what it is not.

People have been undertaking projects since the earliest days of organized human activity. The hunting parties of our prehistoric ancestors were projects, for example; they were temporary undertakings directed at the goal of obtaining meat for the community. Large complex projects have also been with us for a long time. The pyramids and the Great Wall of China were in their day of roughly the same dimensions as the Apollo project to send men to the moon. We use the term "project" frequently in our daily conversations. A husband, for example may tell his wife, "My main project for this weekend is to straighten out the garage". Going hunting, building pyramids, and fixing faucets all share certain features that make them projects.

Project Attributes

A project has distinctive attributes that distinguish it from ongoing work or business operations. Projects are temporary in nature. They are not an everyday business process and have definitive start dates and end dates. This characteristic is important because a large part of the project effort is dedicated to ensuring that the project is completed at the appointed time. To do this, schedules are created showing when tasks should begin and end. Projects can last minutes, hours, days, weeks, months, or years.

Projects exist to bring about a product or service that hasn't existed before. In this sense, a project is unique. Unique means that this is new; this has never been done before. Maybe it's been done in a very similar fashion before but never exactly in this way. For example, Ford Motor Company is in the business of designing and assembling cars. Each model that Ford designs and produces can be considered a project. The models differ from each other in their features and are marketed to people with various needs. An SUV serves a different purpose and clientele than a luxury car. The design and marketing of these two models are unique projects. However, the actual assembly of the cars is considered an operation (i.e., a repetitive process that is followed for most makes and models).

In contrast with projects, operations are ongoing and repetitive. They involve work that is continuous without an ending date and with the same processes repeated to produce the same results. The purpose of operations is to keep the organization functioning while the purpose of a project is to meet its goals and conclude. Therefore, operations are ongoing while projects are unique and temporary.

A project is completed when its goals and objectives are accomplished. It is these goals that drive the project, and all the planning and implementation efforts undertaken to achieve them. Sometimes projects end when it is determined that the goals and objectives cannot be accomplished or when the product or service of the project is no longer needed and the project is cancelled.

Definition of a Project

There are many written definitions of a project. All of them contain the key elements described above. For those looking for a formal definition of a project, the Project Management Institute (PMI) defines a project as a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates a definite beginning and end. The end is reached when the project's objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists.

Project Characteristics

When considering whether or not you have a project on your hands, there are some things to keep in mind. First, is it a project or an ongoing operation? Second, if it is a project, who are the stakeholders? And third, what characteristics distinguish this endeavor as a project?

Projects have several characteristics:

• Projects are unique.
• Projects are temporary in nature and have a definite beginning and ending date.
• Projects are completed when the project goals are achieved or it's determined the project is no longer viable.

A successful project is one that meets or exceeds the expectations of the stakeholders.

Consider the following scenario: The vice-president (VP) of marketing approaches you with a fabulous idea. (Obviously it must be "fabulous" because he thought of it.) He wants to set up kiosks in local grocery stores as mini-offices. These offices will offer customers the ability to sign up for car and home insurance services as well as make their bill payments. He believes that the exposure in grocery stores will increase awareness of the company's offerings. He told you that senior management has already cleared the project, and he'll dedicate as many resources to this as he can. He wants the new kiosks in place in 12 selected stores in a major city by the end of the year. Finally, he has assigned you to head up this project.

Your first question should be, "Is it a project?" This may seem elementary, but confusing projects with ongoing operations happens often. Projects are temporary in nature, have definite start and end dates, result in the creation of a unique product or service, and are completed when their goals and objectives have been met and signed off by the stakeholders.

Using these criteria, let's examine the assignment from the VP of marketing to determine if it is a project:

• Is it unique? Yes, because the kiosks don't exist in the local grocery stores. This is a new way of offering the company's services to its customer base. While the service the company is offering isn't new, the way it is presenting its services is.
• Does the product have a limited timeframe? Yes, the start date of this project is today, and the end date is the end of next year. It is a temporary endeavor.
• Is there a way to determine when the project is completed? Yes, the kiosks will be installed and the services will be offered from them. Once all the kiosks are installed and operating, the project will come to a close.
• Is there a way to determine stakeholder satisfaction? Yes, the expectations of the stakeholders will be documented in the form of requirements during the planning processes. These requirements will be compared to the finished product to determine if it meets the expectations of the stakeholder.

If the answer is yes to all these questions, then we have a project.

The Process of Project Management

You've determined that you have a project. What now? The notes you scribbled down on the back of the napkin at lunch are a start, but not exactly good project management practice. Too often, organizations follow Nike's advice when it comes to managing projects when they "just do it". An assignment is made, and the project team members jump directly into the development of the product or service requested. In the end, the delivered product doesn't meet the expectations of the customer. Unfortunately, many projects follow this poorly constructed path, and that is a primary contributor to a large percentage of projects not meeting their original objectives, as defined by performance, schedule, and budget.

In the United States, more than $250 billion is spent each year on information technology (IT) application development in approximately 175,000 projects. The Standish Group (a Boston-based leader in project and value performance research) released the summary version of their 2009 CHAOS Report that tracks project failure rates across a broad range of companies and industries (Figure 2.1).

Figure 2.1: Summary of 2009 Standish Group CHAOS report.

Jim Johnson, chairman of the Standish Group, has stated that "this year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions, 44% were challenged-which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used".

When are companies going to stop wasting billions of dollars on failed projects? The vast majority of this waste is completely avoidable: simply get the right business needs (requirements) understood early in the process and ensure that project management techniques are applied and followed, and the project activities are monitored.

Applying good project management discipline is the way to help reduce the risks. Having good project management skills does not completely eliminate problems, risks, or surprises. The value of good project management is that you have standard processes in place to deal with all contingencies.

Project management is the application of knowledge, skills, tools, and techniques applied to project activities in order to meet the project requirements. Project management is a process that includes planning, putting the project plan into action, and measuring progress and performance.

Managing a project includes identifying your project's requirements and writing down what everyone needs from the project. What are the objectives for your project? When everyone understands the goal, it's much easier to keep them all on the right path. Make sure you set goals that everyone agrees on to avoid team conflicts later on. Understanding and addressing the needs of everyone affected by the project means the end result of your project is far more likely to satisfy your stakeholders. Last but not least, as project manager, you will also be balancing the many competing project constraints.

On any project, you will have a number of project constraints that are competing for your attention. They are cost, scope, quality, risk, resources, and time.

• Cost is the budget approved for the project including all necessary expenses needed to deliver the project. Within organizations, project managers have to balance between not running out of money and not underspending because many projects receive funds or grants that have contract clauses with a "use it or lose it" approach to project funds. Poorly executed budget plans can result in a last-minute rush to spend the allocated funds. For virtually all projects, cost is ultimately a limiting constraint; few projects can go over budget without eventually requiring a corrective action.
• Scope is what the project is trying to achieve. It entails all the work involved in delivering the project outcomes and the processes used to produce them. It is the reason and the purpose of the project.
• Quality is a combination of the standards and criteria to which the project's products must be delivered for them to perform effectively. The product must perform to provide the functionality expected, solve the identified problem, and deliver the benefit and value expected. It must also meet other performance requirements, or service levels, such as availability, reliability, and maintainability, and have acceptable finish and polish. Quality on a project is controlled through quality assurance (QA), which is the process of evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards.
• Risk is defined by potential external events that will have a negative impact on your project if they occur. Risk refers to the combination of the probability the event will occur and the impact on the project if the event occurs. If the combination of the probability of the occurrence and the impact on the project is too high, you should identify the potential event as a risk and put a proactive plan in place to manage the risk.
• Resources are required to carry out the project tasks. They can be people, equipment, facilities, funding, or anything else capable of definition (usually other than labour) required for the completion of a project activity.
• Time is defined as the time to complete the project. Time is often the most frequent project oversight in developing projects. This is reflected in missed deadlines and incomplete deliverables. Proper control of the schedule requires the careful identification of tasks to be performed and accurate estimations of their durations, the sequence in which they are going to be done, and how people and other resources are to be allocated. Any schedule should take into account vacations and holidays.

You may have heard of the term "triple constraint," which traditionally consisted of only time, cost, and scope. These are the primary competing project constraints that you have to be most aware of. The triple constraint is illustrated in the form of a triangle to visualize the project work and see the relationship between the scope/quality, schedule/time, and cost/resource (Figure 2.2). In this triangle, each side represents one of the constraints (or related constraints) wherein any changes to any one side cause a change in the other sides. The best projects have a perfectly balanced triangle. Maintaining this balance is difficult because projects are prone to change. For example, if scope increases, cost and time may increase disproportionately. Alternatively, if the amount of money you have for your project decreases, you may be able to do as much, but your time may increase.

Figure 2.2: A schematic of the triple constraint triangle.

Your project may have additional constraints that you must face, and as the project manager, you have to balance the needs of these constraints against the needs of the stakeholders and your project goals. For instance, if your sponsor wants to add functionality to the original scope, you will very likely need more money to finish the project, or if they cut the budget, you will have to reduce the quality of your scope, and if you don't get the appropriate resources to work on your project tasks, you will have to extend your schedule because the resources you have take much longer to finish the work.

You get the idea; the constraints are all dependent on each other. Think of all of these constraints as the classic carnival game of Whac-a-mole (Figure 2.3). Each time you try to push one mole back in the hole, another one pops out. The best advice is to rely on your project team to keep these moles in place.

Figure 2.3: Whac-a-mole.

Here is an example of a project that cut quality because the project costs were fixed. The P-36 oil platform (Figure 2.4) was the largest footing production platform in the world capable of processing 180,000 barrels of oil per day and 5.2 million cubic metres of gas per day. Located in the Roncador Field, Campos Basin, Brazil, the P-36 was operated by Petrobras.

Figure 2.4: The Petrobras P-36 oil platform sinking.

In March 2001, the P-36 was producing around 84,000 barrels of oil and 1.3 million cubic metres of gas per day when it became destabilized by two explosions and subsequently sank in 3,900 feet of water with 1,650 short tons of crude oil remaining on board, killing 11 people. The sinking is attributed to a complete failure in quality assurance, and pressure for increased production led to corners being cut on safety procedures. It is listed as one of the most expensive accidents with a price tag of $515,000,000.

The following quotes are from a Petrobras executive, citing the benefits of cutting quality assurance and inspection costs on the project.

The dynamic trade-offs between the project constraint values have been humorously and accurately described in Figure 2.5.

Figure 2.5: Good, Quick, Cheap: Choose two. A sign seen at an automotive repair shop.

Project Management Expertise

In order for you, as the project manager, to manage the competing project constraints and the project as a whole, there are some areas of expertise you should bring to the project team (Figure 2.11). They are knowledge of the application area and the standards and regulations in your industry, understanding of the project environment, general management knowledge and skills, and interpersonal skills. It should be noted that industry expertise is not in a certain field but the expertise to run the project. So while knowledge of the type of industry is important, you will have a project team supporting you in this endeavor. For example, if you are managing a project that is building an oil platform, you would not be expected to have a detailed understanding of the engineering since your team will have mechanical and civil engineers who will provide the appropriate expertise; however, it would definitely help if you understood this type of work.

Let's take a look at each of these areas in more detail.

Application knowledge

By standards, we mean guidelines or preferred approaches that are not necessarily mandatory. In contrast, when referring to regulations we mean mandatory rules that must be followed, such as government-imposed requirements through laws. It should go without saying that as a professional, you're required to follow all applicable laws and rules that apply to your industry, organization, or project. Every industry has standards and regulations. Knowing which ones affect your project before you begin work will not only help the project to unfold smoothly, but will also allow for effective risk analysis.

Figure 2.6: Areas of expertise that a project manager should bring to the project team.

Some projects require specific skills in certain application areas. Application areas are made up of categories of projects that have common elements. They can be defined by industry group (pharmaceutical, financial, etc.), department (accounting, marketing, legal, etc.), technology (software development, engineering, etc), or management specialties (procurement, research and development, etc.). These application areas are usually concerned with disciplines, regulations, and the specific needs of the project, the customer, or the industry. For example, most government agencies have specific procurement rules that apply to their projects that wouldn't be applicable in the construction industry. The pharmaceutical industry is interested in regulations set forth by government regulators, whereas the automotive industry has little or no concern for either of these types of regulations. You need to stay up-to-date regarding your industry so that you can apply your knowledge effectively. Today's fast-paced advances can leave you behind fairly quickly if you don't stay abreast of current trends.

Having some level of experience in the application area you're working in will give you an advantage when it comes to project management. While you can call in experts who have the application area knowledge, it doesn't hurt for you to understand the specific aspects of the application areas of your project.

Understanding the Project Environment

There are many factors that need to be understood within your project environment (Figure 2.7). At one level, you need to think in terms of the cultural and social environments (i.e., people, demographics, and education). The international and political environment is where you need to understand about different countries' cultural influences. Then we move to the physical environment; here we think about time zones. Think about different countries and how differently your project will be executed whether it is just in your country or if it involves an international project team that is distributed throughout the world in five different countries.

Figure 2.7: The important factors to consider within the project environment.

Of all the factors, the physical ones are the easiest to understand, and it is the cultural and international factors that are often misunderstood or ignored. How we deal with clients, customers, or project members from other countries can be critical to the success of the project. For example, the culture of the United States values accomplishments and individualism. Americans tend to be informal and call each other by first names, even if having just met. Europeans tend to be more formal, using surnames instead of first names in a business setting, even if they know each other well. In addition, their communication style is more formal than in the United States, and while they tend to value individualism, they also value history, hierarchy, and loyalty. The Japanese, on the other hand, tend to communicate indirectly and consider themselves part of a group, not as individuals. The Japanese value hard work and success, as most of us do.

How a product is received can be very dependent on the international cultural differences. For example, in the 1990s, when many large American and European telecommunications companies were cultivating new markets in Asia, their customer's cultural differences often produced unexpected situations. Western companies planned their telephone systems to work the same way in Asia as they did in Europe and the United States. But the protocol of conversation was different. Call-waiting, a popular feature in the West, is considered impolite in some parts of Asia. This cultural blunder could have been avoided had the team captured the project environment requirements and involved the customer.

It is often the simplest things that can cause trouble since, unsurprisingly, in different countries, people do things differently. One of the most notorious examples of this is also one of the most simple: date formats. What day and month is 2/8/2009? Of course it depends where you come from; in North America it is February 8th while in Europe (and much of the rest of the world) it is 2nd August. Clearly, when schedules and deadlines are being defined it is important that everyone is clear on the format used.

The diversity of practices and cultures and its impact on products in general and on software in particular goes well beyond the date issue. You may be managing a project to create a new website for a company that sells products worldwide. There are language and presentation style issues to take into consideration; converting the site into different languages isn't enough. It is obvious that you need to ensure the translation is correct; however, the presentation layer will have its own set of requirements for different cultures. The left side of a website may be the first focus of attention for a Canadian; the right side would be the initial focus for anyone from the Middle East, as both Arabic and Hebrew are written from right to left. Colors also have different meanings in different cultures. White, which is a sign of purity in North America (e.g., a bride's wedding dress), and thus would be a favoured background colour in North America, signifies death in Japan (e.g., a burial shroud). Table 2.1 summarizes different meanings of common colours.

Table 2.1: The meaning of colours in various cultures. 

Colour	United States	China	Japan	Egypt	France
Red	Danger, stop	Happiness	Anger, danger	Death	Aristocracy
Blue	Sadness, melancholy	Heavens, clouds	Villainy	Virtue, faith, truth	Freedom, peace
Green	Novice, apprentice	Ming dynasty, heavens	Future, youth, energy	Fertility, strength	Criminality
Yellow	Cowardice	Birth, wealth	Grace, nobility	Happiness, prosperity	Temporary
White	Purity	Death, purity	Death	Joy	Neutrality

Project managers in multicultural projects must appreciate the culture dimensions and try to learn relevant customs, courtesies, and business protocols before taking responsibility for managing an international project. A project manager must take into consideration these various cultural influences and how they may affect the project's completion, schedule, scope, and cost.

Management Knowledge and Skills

As the project manager, you have to rely on your project management knowledge and your general manage­ment skills. Here, we are thinking of items like your ability to plan the project, execute it properly, and of course control it and bring it to a successful conclusion, along with your ability to guide the project team to achieve project objectives and balance project constraints.

There is more to project management than just getting the work done. Inherent in the process of project management are the general management skills that allow the project manager to complete the project with some level of efficiency and control. In some respects, managing a project is similar to running a business: there are risk and rewards, finance and accounting activities, human resource issues, time management, stress management, and a purpose for the project to exist. General management skills are needed in every project.

Interpersonal Skills

Last but not least you also have to bring the ability into the project to manage personal relationships and deal with personnel issues as they arise. Here were talking about your interpersonal skills as shown in Figure 2.8.

Communication

Project managers spend 90% of their time communicating. Therefore they must be good communicators, promoting clear, unambiguous exchange of information. As a project manager, it is your job to keep a number of people well informed. It is essential that your project staff know what is expected of them: what they have to do, when they have to do it, and what budget and time constraints and quality specifications they are working toward. If project staff members do not know what their tasks are, or how to accomplish them, then the entire project will grind to a halt. If you do not know what the project staff is (or often is not) doing, then you will be unable to monitor project progress. Finally, if you are uncertain of what the customer expects of you, then the project will not even get off the ground. Project communication can thus be summed up as knowing "who needs what information and when" and making sure they have it.

Figure 2.8: Interpersonal skills required of a project manager.

All projects require sound communication plans, but not all projects will have the same types of commu­nication or the same methods for distributing the information. For example, will information be distributed via mail or email, is there a shared website, or are face-to-face meetings required? The communication management plan documents how the communication needs of the stakeholders will be met, including the types of information that will be communicated, who will communicate them, and who will receive them; the methods used to communicate; the timing and frequency of communication; the method for updating the plan as the project progresses, including the escalation process; and a glossary of common terms.

Influence

Project management is about getting things done. Every organization is different in its policies, modes of operations, and underlying culture. There are political alliances, differing motivations, conflicting interests, and power struggles. A project manager must understand all of the unspoken influences at work within an organization.

Leadership

Leadership is the ability to motivate and inspire individuals to work toward expected results. Leaders inspire vision and rally people around common goals. A good project manager can motivate and inspire the project team to see the vision and value of the project. The project manager as a leader can inspire the project team to find a solution to overcome perceived obstacles to get the work done.

Motivation

Motivation helps people work more efficiently and produce better results. Motivation is a constant process that the project manager must guide to help the team move toward completion with passion and a profound reason to complete the work. Motivating the team is accomplished by using a variety of team-building techniques and exercises. Team building is simply getting a diverse group of people to work together in the most efficient and effective manner possible. This may involve management events as well as individual actions designed to improve team performance.

Recognition and rewards are an important part of team motivations. They are formal ways of recognizing and promoting desirable behaviour and are most effective when carried out by the management team and the project manager. Consider individual preferences and cultural differences when using rewards and recognition. Some people don't like to be recognized in front of a group; others thrive on it.

Negotiation

Project managers must negotiate for the good of the project. In any project, the project manager, the project sponsor, and the project team will have to negotiate with stakeholders, vendors, and customers to reach a level of agreement acceptable to all parties involved in the negotiation process.

Problem Solving

Problem solving is the ability to understand the heart of a problem, look for a viable solution, and then make a decision to implement that solution. The starting point for problem solving is problem definition. Problem definition is the ability to understand the cause and effect of the problem; this centres on root-cause analysis. If a project manager treats only the symptoms of a problem rather than its cause, the symptoms will perpetuate and continue through the project life. Even worse, treating a symptom may result in a greater problem. For example, increasing the ampere rating of a fuse in your car because the old one keeps blowing does not solve the problem of an electrical short that could result in a fire. Root-cause analysis looks beyond the immediate symptoms to the cause of the symptoms, which then affords opportunities for solutions. Once the root of a problem has been identified, a decision must be made to effectively address the problem.

Solutions can be presented from vendors, the project team, the project manager, or various stakeholders. A viable solution focuses on more than just the problem; it looks at the cause and effect of the solution itself. In addition, a timely decision is needed or the window of opportunity may pass and then a new decision will be needed to address the problem. As in most cases, the worst thing you can do is nothing.

All of these interpersonal skills will be used in all areas of project management. Start practicing now because it's guaranteed that you'll need these skills on your next project.

Framework for Project Management

Many different professions contribute to the theory and practice of project management. Engineers and architects have been managing major projects since pre-history. Since approximately the 1960s, there have been efforts to professionalize the practice of project management as a specialization of its own. There are many active debates around this: Should project management be a profession in the same way as engineering, accounting, and medicine? These have professional associations that certify who is legally allowed to use the job title, and who can legally practice the profession. They also provide a level of assurance of quality and discipline members who behave inappropriately. Another ongoing debate is: How much industry knowledge is required of a seasoned project manager? How easily can a project manager from one industry, say, IT, transition to another industry such as hospitality?

There are two major organizations with worldwide impact on the practice of project management: the Project Management Institute (PMI), with world headquarters in the United States, and the International Project Management Association (IPMA), with world headquarters in Switzerland. This textbook takes an approach that is closer to the PMI approach. More details are included in this chapter, along with a section on the project management office.

Project Management Institute Overview

Five volunteers founded the Project Management Institute (PMI) in 1969. Their initial goal was to establish an organization where members could share their experiences in project management and discuss issues. Today, PMI is a non-profit project management professional association and the most widely recognized organization in terms of promoting project management best practices. PMI was formed to serve the interests of the project management industry. The premise of PMI is that the tools and techniques of project management are common even among the widespread application of projects from the software to the construction industry. PMI first began offering the Project Management Professional (PMP) certification exam in 1984. Although it took a while for people to take notice, now more than 590,000 individuals around the world hold the PMP designation.

To help keep project management terms and concepts clear and consistent, PMI introduced the book A Guide to the Project Management Body of Knowledge (PMBOK Guide) in 1987. It was updated it in 1996, 2000, 2004, 2009, and most recently in 2013 as the fifth edition. At present, there are more than one million copies of the PMBOK Guide in circulation. The highly regarded Institute of Electrical and Electronics Engineers (IEEE) has adopted it as their project management standard. In 1999 PMI was accredited as an American National Standards Institute (ANSI) standards developer and also has the distinction of being the first organization to have its certification program attain International Organization for Standardization (ISO) 9001 recognition. In 2008, the organization reported more than 260,000 members in over 171 countries. PMI has its headquarters in Pennsylvania, United States, and also has offices in Washington, DC, and in Canada, Mexico, and China, as well as having regional service centres in Singapore, Brussels (Belgium), and New Delhi (India). Recently, an office was opened in Mumbai (India).

Because of the importance of projects, the discipline of project management has evolved into a working body of knowledge known as PMBOK – Project Management Body of Knowledge. The PMI is responsible for developing and promoting PMBOK. PMI also administers a professional certification program for project managers, the PMP. So if you want to get grounded in project management, PMBOK is the place to start, and if you want to make project management your profession, then you should consider becoming a PMP.

So what is PMBOK?

PMBOK is the fundamental knowledge you need for managing a project, categorized into 10 knowledge areas:

1. Managing integration: Projects have all types of activities going on and there is a need to keep the “whole” thing moving collectively – integrating all of the dynamics that take place. Managing integration is about developing the project charter, scope statement, and plan to direct, manage, monitor, and control project change.
2. Managing scope: Projects need to have a defined parameter or scope, and this must be broken down and managed through a work breakdown structure or WBS. Managing scope is about planning, definition, WBS creation, verification, and control.
3. Managing time/schedule: Projects have a definite beginning and a definite ending date. Therefore, there is a need to manage the budgeted time according to a project schedule. Managing time/schedule is about definition, sequencing, resource and duration estimating, schedule development, and schedule control.
4. Managing costs: Projects consume resources, and therefore, there is a need to manage the investment with the realization of creating value (i.e., the benefits derived exceed the amount spent). Managing costs is about resource planning, cost estimating, budgeting, and control.
5. Managing quality: Projects involve specific deliverables or work products. These deliverables need to meet project objectives and performance standards. Managing quality is about quality planning, quality assurance, and quality control.
6. Managing human resources: Projects consist of teams and you need to manage project team(s) during the life cycle of the project. Finding the right people, managing their outputs, and keeping them on schedule is a big part of managing a project. Managing human resources is about human resources planning, hiring, and developing and managing a project team.
7. Managing communication: Projects invariably touch lots of people, not just the end users (customers) who benefit directly from the project outcomes. This can include project participants, managers who oversee the project, and external stakeholders who have an interest in the success of the project. Managing communication is about communications planning, information distribution, performance reporting, and stakeholder management.
8. Managing risk: Projects are a discovery-driven process, often uncovering new customer needs and identifying critical issues not previously disclosed. Projects also encounter unexpected events, such as project team members resigning, budgeted resources suddenly changing, the organization becoming unstable, and newer technologies being introduced. There is a real need to properly identify various risks and manage these risks. Managing risk is about risk planning and identification, risk analysis (qualitative and quantitative), risk response (action) planning, and risk monitoring and control.
9. Managing procurement: Projects procure the services of outside vendors and contractors, including the purchase of equipment. There is a need to manage how vendors are selected and managed within the project life cycle. Managing procurement is about acquisition and contracting plans, sellers’ responses and selections, contract administration, and contract closure.
10. Managing stakeholders: Every project impacts people and organizations and is impacted by people and organizations. Identifying these stakeholders early, and as they arise and change throughout the project, is a key success factor. Managing stakeholders is about identifying stakeholders, their interest level, and their potential to influence the project; and managing and controlling the relationships and communications between stakeholders and the project.

This is the big framework for managing projects and if you want to be effective in managing projects, then you need to be effective in managing each of the 10 knowledge areas that make up PMBOK (see Figure 4.1)

Figure 4.1: PM Star Model suggested by GeekDisplaced

Certification in project management is available from the PMI, PRINCE2, ITIL, Critical Chain, and others. Agile project management methodologies (Scrum, extreme programming, Lean Six Sigma, others) also have certifications.

Introduction to the Project Management Knowledge Areas

As discussed above, projects are divided into components, and a project manager must be knowledgeable in each area. Each of these areas of knowledge will be explored in more depth in subsequent chapters. For now, lets look at them in a little more detail to prepare you for the chapters that follow.

Project Start-Up and Integration

The start-up of a project is similar to the start-up of a new organization. The project leader develops the project infrastructure used to design and execute the project. The project management team must develop alignment among the major stakeholders—those who have a share or interest—on the project during the early phases or definition phases of the project. The project manager will conduct one or more kickoff meetings or alignment sessions to bring the various parties of the project together and begin the project team building required to operate efficiently during the project.

During project start-up, the project management team refines the scope of work and develops a preliminary schedule and conceptual budget. The project team builds a plan for executing the project based on the project profile. The plan for developing and tracking the detailed schedule, the procurement plan, and the plan for building the budget and estimating and tracking costs are developed during the start-up. The plans for information technology, communication, and tracking client satisfaction are also all developed during the start-up phase of the project.

Flowcharts, diagrams, and responsibility matrices are tools to capture the work processes associated with executing the project plan. The first draft of the project procedures manual captures the historic and intuitional knowledge that team members bring to the project. The development and review of these procedures and work processes contribute to the development of the organizational structure of the project.

This is typically an exciting time on a project where all things are possible. The project management team is working many hours developing the initial plan, staffing the project, and building relationships with the client. The project manager sets the tone of the project and sets expectations for each of the project team members. The project start-up phase on complex projects can be chaotic, and until plans are developed, the project manager becomes the source of information and direction. The project manager creates an environment that encourages team members to fully engage in the project and encourages innovative approaches to developing the project plan.

Project Scope

The project scope is a document that defines the parameters—factors that define a system and determine its behaviour—of the project, what work is done within the boundaries of the project, and the work that is outside the project boundaries. The scope of work (SOW) is typically a written document that defines what work will be accomplished by the end of the project—the deliverables of the project. The project scope defines what will be done, and the project execution plan defines how the work will be accomplished.

No template works for all projects. Some projects have a very detailed scope of work, and some have a short summary document. The quality of the scope is measured by the ability of the project manager and project stakeholders to develop and maintain a common understanding of what products or services the project will deliver. The size and detail of the project scope is related to the complexity profile of the project. A more complex project often requires a more detailed and comprehensive scope document.

According to the PMI, the scope statement should include the following:

• Description of the scope
• Product acceptance criteria
• Project deliverables
• Project exclusions
• Project constraints
• Project assumptions

The scope document is the basis for agreement by all parties. A clear project scope document is also critical to managing change on a project. Since the project scope reflects what work will be accomplished on the project, any change in expectations that is not captured and documented creates the opportunity for confusion. One of the most common trends on projects is the incremental expansion in the project scope. This trend is labeled “scope creep.” Scope creep threatens the success of a project because the small increases in scope require additional resources that were not in the plan. Increasing the scope of the project is a common occurrence, and adjustments are made to the project budget and schedule to account for these changes. Scope creep occurs when these changes are not recognized or not managed. The ability of a project manager to identify potential changes is often related to the quality of the scope documents.

Events do occur that require the scope of the project to change. Changes in the marketplace may require change in a product design or the timing of the product delivery. Changes in the client’s management team or the financial health of the client may also result in changes in the project scope. Changes in the project schedule, budget, or product quality will have an effect on the project plan. Generally, the later in the project the change occurs, the greater the increase to the project costs. Establishing a change management system for the project that captures changes to the project scope and assures that these changes are authorized by the appropriate level of management in the client’s organization is the responsibility of the project manager. The project manager also analyzes the cost and schedule impact of these changes and adjusts the project plan to reflect the changes authorized by the client. Changes to the scope can cause costs to increase or decrease.

Project Schedule and Time Management

The definition of project success often includes completing the project on time. The development and management of a project schedule that will complete the project on time is a primary responsibility of the project manager, and completing the project on time requires the development of a realistic plan and the effective management of the plan. On smaller projects, project managers may lead the development of the project plan and build a schedule to meet that plan. On larger and more complex projects, a project controls team that focuses on both costs and schedule planning and controlling functions will assist the project management team in developing the plan and tracking progress against the plan.

To develop the project schedule, the project team does an analysis of the project scope, contract, and other information that helps the team define the project deliverables. Based on this information, the project team develops a milestone schedule. The milestone schedule establishes key dates throughout the life of a project that must be met for the project to finish on time. The key dates are often established to meet contractual obligations or established intervals that will reflect appropriate progress for the project. For less complex projects, a milestone schedule may be sufficient for tracking the progress of the project. For more complex projects, a more detailed schedule is required.

To develop a more detailed schedule, the project team first develops a work breakdown structure (WBS)—a description of tasks arranged in layers of detail. Although the project scope is the primary document for developing the WBS, the WBS incorporates all project deliverables and reflects any documents or information that clarifies the project deliverables. From the WBS, a project plan is developed. The project plan lists the activities that are needed to accomplish the work identified in the WBS. The more detailed the WBS, the more activities that are identified to accomplish the work.

After the project team identifies the activities, the team sequences the activities according to the order in which the activities are to be accomplished. An outcome from the work process is the project logic diagram. The logic diagram represents the logical sequence of the activities needed to complete the project. The next step in the planning process is to develop an estimation of the time it will take to accomplish each activity or the activity duration. Some activities must be done sequentially, and some activities can be done concurrently. The planning process creates a project schedule by scheduling activities in a way that effectively and efficiently uses project resources and completes the project in the shortest time.

On larger projects, several paths are created that represent a sequence of activities from the beginning to the end of the project. The longest path to the completion of the project is the critical path. If the critical path takes less time than is allowed by the client to complete the project, the project has a positive total float or project slack. If the client’s project completion date precedes the calculated critical path end date, the project has a negative float. Understanding and managing activities on the critical path is an important project management skill.

To successfully manage a project, the project manager must also know how to accelerate a schedule to compensate for unanticipated events that delay critical activities. Compressing—crashing—the schedule is a term used to describe the techniques used to shorten the project schedule. During the life of the project, scheduling conflicts often occur, and the project manager is responsible for reducing these conflicts while maintaining project quality and meeting cost goals.

Project Costs

The definition of project success often includes completing the project within budget. Developing and controlling a project budget that will accomplish the project objectives is a critical project management skill. Although clients expect the project to be executed efficiently, cost pressures vary on projects. On some projects, the project completion or end date is the largest contributor to the project complexity. The development of a new drug to address a critical health issue, the production of a new product that will generate critical cash flow for a company, and the competitive advantage for a company to be first in the marketplace with a new technology are examples of projects with schedule pressures that override project costs.

The accuracy of the project budget is related to the amount of information known by the project team. In the early stages of the project, the amount of information needed to develop a detailed budget is often missing. To address the lack of information, the project team develops different levels of project budget estimates. The conceptual estimate (or “ballpark estimate”) is developed with the least amount of knowledge. The major input into the conceptual estimate is expert knowledge or past experience. A project manager who has executed a similar project in the past can use those costs to estimate the costs of the current project.

When more information is known, the project team can develop a rough order of magnitude (ROM) estimate. Additional information such as the approximate square feet of a building, the production capacity of a plant, and the approximate number of hours needed to develop a software program can provide a basis for providing a ROM estimate. After a project design is more complete, a project detailed estimate can be developed. For example, when the project team knows the number of rooms, the type of materials, and the building location of a home, they can provide a detailed estimate. A detailed estimate is not a bid.

The cost of the project is tracked relative to the progress of the work and the estimate for accomplishing that work. Based on the cost estimate, the cost of the work performed is compared against the cost budgeted for that work. If the cost is significantly higher or lower, the project team explores reasons for the difference between expected costs and actual costs.

Project costs may deviate from the budget because the prices in the marketplace were different from what was expected. For example, the estimated costs for lumber on a housing project may be higher than budgeted or the hourly cost for labour may be lower than budgeted. Project costs may also deviate based on project performance. For example, a project team estimated that the steel design for a bridge over a river would take 800 labour hours, but 846 hours were actually expended. The project team captures the deviation between costs budgeted for work and the actual cost for work, revises the estimate as needed, and takes corrective action if the deviation appears to reflect a trend.

The project manager is responsible for assuring that the project team develops cost estimates based on the best information available and revises those estimates as new or better information becomes available. The project manager is also responsible for tracking costs against the budget and conducting an analysis when project costs deviate significantly from the project estimate. The project manager then takes appropriate corrective action to ensure that project performance matches the revised project plan.

Project Quality

Project quality focuses on the end product or service deliverables that reflect the purpose of the project. The project manager is responsible for developing a project execution approach that provides for a clear understanding of the expected project deliverables and the quality specifications. The project manager of a housing construction project not only needs to understand which rooms in the house will be carpeted but also what grade of carpet is needed. A room with a high volume of traffic will need a high-grade carpet.

The project manager is responsible for developing a project quality plan that defines the quality expectations and ensures that the specifications and expectations are met. Developing a good understanding of the project deliverables through documenting specifications and expectations is critical to a good quality plan. The processes for ensuring that the specifications and expectations are met are integrated into the project execution plan. Just as the project budget and completion dates may change over the life of a project, the project specifications may also change. Changes in quality specifications are typically managed in the same process as cost or schedule changes. The impact of the changes is analyzed for impact on cost and schedule, and with appropriate approvals, changes are made to the project execution plan.

The PMI’s A Guide to the Project Management Body of Knowledge (PMBOK Guide) has an extensive chapter on project quality management. The material found in this chapter would be similar to material found in a good operational management text.

Although any of the quality management techniques designed to make incremental improvement to work processes can be applied to a project work process, the character of a project (unique and relatively short in duration) makes small improvements less attractive on projects. Rework on projects, as with manufacturing operations, increases the cost of the product or service and often increases the time needed to complete the reworked activities. Because of the duration constraints of a project, the development of the appropriate skills, materials, and work processes early in the project is critical to project success. On more complex projects, time is allocated to developing a plan to understand and develop the appropriate levels of skills and work processes.

Project management organizations that execute several similar types of projects may find process improvement tools useful in identifying and improving the baseline processes used on their projects. Process improvement tools may also be helpful in identifying cost and schedule improvement opportunities. Opportunities for improvement must be found quickly to influence project performance. The investment in time and resources to find improvements is greatest during the early stages of the project, when the project is in the planning stages. During later project stages, as pressures to meet project schedule goals increase, the culture of the project is less conducive to making changes in work processes.

Another opportunity for applying process improvement tools is on projects that have repetitive processes. A housing contractor that is building several identical houses may benefit from evaluating work processes in the first few houses to explore the opportunities available to improve the work processes. The investment of $1,000 in a work process that saves $200 per house is a good investment as long as the contractor is building more than five houses.

Project Team: Human Resources and Communications

Staffing the project with the right skills, at the right place, and at the right time is an important responsibility of the project management team. The project usually has two types of team members: functional managers and process managers. The functional managers and team focus on the technology of the project. On a construction project, the functional managers would include the engineering manager and construction superintendents. On a training project, the functional manager would include the professional trainers; on an information technology project, the software development managers would be functional managers. The project management team also includes project process managers. The project controls team would include process managers who have expertise in estimating, cost tracking, planning, and scheduling. The project manager needs functional and process expertise to plan and execute a successful project.

Because projects are temporary, the staffing plan for a project typically reflects both the long-term goals of skilled team members needed for the project and short-term commitment that reflects the nature of the project. Exact start and end dates for team members are often negotiated to best meet the needs of individuals and the project. The staffing plan is also determined by the different phases of the project. Team members needed in the early or conceptual phases of the project are often not needed during the later phases or project closeout phases. Team members needed during the implementation phase are often not needed during the conceptual or closeout phases. Each phase has staffing requirements, and the staffing of a complex project requires detailed planning to have the right skills, at the right place, at the right time.

Typically a core project management team is dedicated to the project from start-up to closeout. This core team would include members of the project management team: project manager, project controls, project procurement, and key members of the function management or experts in the technology of the project. Although longer projects may experience more team turnover than shorter projects, it is important on all projects to have team members who can provide continuity through the project phases.

For example, on a large commercial building project, the civil engineering team that designs the site work where the building will be constructed would make their largest contribution during the early phases of the design. The civil engineering lead would bring on different civil engineering specialties as they were needed. As the civil engineering work is completed and the structural engineering is well underway, a large portion of the civil engineers would be released from the project. The functional managers, the engineering manager, and civil engineering lead would provide expertise during the entire length of the project, addressing technical questions that may arise and addressing change requests.

Project team members can be assigned to the project from a number of different sources. The organization that charters the project can assign talented managers and staff from functional units within the organization, contract with individuals or agencies to staff positions on the project, temporarily hire staff for the project, or use any combination of these staffing options. This staffing approach allows the project manager to create the project organizational culture. Some project cultures are more structured and detail oriented, and some are less structured with less formal roles and communication requirements. The type of culture the project manager creates depends greatly on the type of project.

Communications

Completing a complex project successfully requires teamwork, and teamwork requires good communication among team members. If those team members work in the same building, they can arrange regular meetings, simply stop by each other’s office space to get a quick answer, or even discuss a project informally at other office functions. Many complex projects in today’s global economy involve team members from widely separated locations, and the types of meetings that work within the same building are not possible. Teams that use electronic methods of communicating without face-to-face meetings are called virtual teams.

Communicating can be divided into two categories: synchronous and asynchronous. If all the parties to the communication are taking part in the exchange at the same time, the communication is synchronous. A telephone conference call is an example of synchronous communication. When the participants are not interacting at the same time, the communication is asynchronous. (The letter a at the beginning of the word means not.) Communications technologies require a variety of compatible devices, software, and service providers, and communication with a global virtual team can involve many different time zones. Establishing effective communications requires a communications plan.

Project Risk

Risk exists on all projects. The role of the project management team is to understand the kinds and levels of risks on the project and then to develop and implement plans to mitigate these risks. Risk represents the likelihood that an event will happen during the life of the project that will negatively affect the achievement of project goals. The type and amount of risk varies by industry type, complexity, and phase of the project. The project risk plan will also reflect the risk profile of the project manager and key stakeholders. People have different comfort levels with risk, and some members of the project team will be more risk averse than others.

The first step in developing a risk management plan involves identifying potential project risks. Some risks are easy to identify, such as the potential for a damaging storm in the Caribbean, and some are less obvious. Many industries or companies have risk checklists developed from past experience. The Construction Industry Institute published a 100-item risk checklist that provides examples and areas of project risks. No risk checklist will include all potential risks. The value of a checklist is the stimulation of discussion and thought about the potential risks on a project.

The project team analyzes the identified risks and estimates the likelihood of the risks occurring. The team then estimates the potential impact on project goals if the event does occur. The outcome from this process is a prioritized list of estimated project risks with a value that represents the likelihood of occurrence and the potential impact on the project.

The project team then develops a risk mitigation plan that reduces the likelihood of an event occurring or reduces the impact on the project if the event does occur. The risk management plan is integrated into the project execution plan, and mitigation activities are assigned to the appropriate project team member. The likelihood that all the potential events identified in the risk analysis would occur is extremely rare. The likelihood that one or more events will happen is high.

The project risk plan reflects the risk profile of the project and balances the investment of the mitigation against the benefit for the project. One of the more common risk mitigation approaches is the use of contingency. Contingency is funds set aside by the project team to address unforeseen events. Projects with a high-risk profile will typically have a large contingency budget. If the team knows which activities have the highest risk, contingency can be allocated to activities with the highest risk. When risks are less identifiable to specific activities, contingency is identified in a separate line item. The plan includes periodic risk-plan reviews during the life of the project. The risk review evaluates the effectiveness of the current plan and explores possible risks not identified in earlier sessions.

Project Procurement

The procurement effort on projects varies widely and depends on the type of project. Often the client organization will provide procurement services on less complex projects. In this case, the project team identifies the materials, equipment, and supplies needed by the project and provides product specifications and a detailed delivery schedule. When the procurement department of the parent organization provides procurement services, a liaison from the project can help the procurement team better understand the unique requirements of the project and the time-sensitive or critical items of the project schedule.

On larger, more complex projects, personnel are dedicated to procuring and managing the equipment, supplies, and materials needed by the project. Because of the temporary nature of projects, equipment, supplies, and materials are procured as part of the product of the project or for the execution of the project. For example, the bricks procured for a construction project would be procured for the product of the project, and the mortar mixer would be equipment procured for the execution of the project work. At the end of the project, equipment bought or rented for the execution of the work of the project are sold, returned to rental organizations, or disposed of some other way.

More complex projects will typically procure through different procurement and management methods. Commodities are common products that are purchased based on the lowest bid. Commodities include items like concrete for building projects, office supplies, or even lab equipment for a research project. The second type of procurement includes products that are specified for the project. Vendors who can produce these products bid for a contract. The awarding of a contract can include price, ability to meet the project schedule, the fit for purpose of the product, and other considerations important to the project. Manufacturing a furnace for a new steel mill would be provided by a project vendor. Equipment especially designed and built for a research project is another example. These vendors’ performances become important parts of the project, and the project manager assigns resources to coordinate the work and schedule of the vendor. The third procurement approach is the development of one or more partners. A design firm that is awarded the design contract for a major part of the steel mill and a research firm that is conducting critical subparts of the research are examples of potential project partners. A partner contributes to and is integrated into the execution plan. Partners perform best when they share the project vision of success and are emotionally invested in the project. The project management team builds and implements a project procurement plan that recognizes the most efficient and effective procurement approach to support the project schedule and goals.

Project Stakeholder Management

People and organizations can have many different relationships to the project. Most commonly, these relationships can be grouped into those who will be impacted by the project and those who can impact the project.

A successful project manager will identify stakeholders early in the project. For each stakeholder, it is important to identify what they want or need and what influence or power they have over the project. Based on this information, the need to communicate with the stakeholder or stakeholder group can be identified, followed by the creation of a stakeholder management plan. A stakeholder register is used to identify and track the interactions between the project and each stakeholder. This register must be updated on a regular basis, as new stakeholders can arise at any time, and the needs and interest levels of a particular stakeholder may change through the course of the project.

Table 4.1 Stakeholder Register

Knowledge Area	Initiating	Planning	Executing	Monitoring and Controlling	Closing
Project Integration Management	Develop Project Charter	Develop Project Management Plan		Monitor and control project work Perform integrated change control	Close project or phase
Project Scope Management		Plan scope management Collect requirements Define scope Create WBS		Validate scope Control scope
Project Time Management		Plan schedule management Define activities Sequence activities Estimate activity resources Estimate activity durations Develop schedule		Control schedule
Project Cost Management		Plan cost management Estimate costs Determine budget		Control costs
Project Quality Management		Plan quality management	Perform quality assurance	Control quality

Scrum Development Overview

“Scrum” is another formal project management/product development methodology and part of agile project management. Scrum is a term from rugby (scrimmage) that means a way of restarting a game. It’s like restarting the project efforts every X weeks. It’s based on the idea that you do not really know how to plan the whole project up front, so you start and build empirical data, and then re-plan and iterate from there.

Scrum uses sequential sprints for development. Sprints are like small project phases (ideally two to four weeks). The idea is to take one day to plan for what can be done now, then develop what was planned for, and demonstrate it at the end of the sprint. Scrum uses a short daily meeting of the development team to check what was done yesterday, what is planned for the next day, and what if anything is impeding the team members from accomplishing what they have committed to. At the end of the sprint, what has been demonstrated can then be tested, and the next sprint cycle starts.

Scrum methodology defines several major roles. They are:

• Product owners: essentially the business owner of the project who knows the industry, the market, the customers, and the business goals of the project. The product owner must be intimately involved with the Scrum process, especially the planning and the demonstration parts of the sprint.

• Scrum Master: somewhat like a project manager, but not exactly. The Scrum Master’s duties are essentially to remove barriers that impede the progress of the development team, teach the product owner how to maximize return on investment (ROI) in terms of development effort, facilitate creativity and empowerment of the team, improve the productivity of the team, improve engineering practices and tools, run daily standup meetings, track progress, and ensure the health of the team.

• Development team: self-organizing (light-touch leadership), empowered group; they participate in planning and estimating for each sprint, do the development, and demonstrate the results at the end of the sprint. It has been shown that the ideal size for a development team is 7 +/- 2. The development team can be broken into “teamlets” that “swarm” on user stories, which are created in the sprint planning session.

Typically, the way a product is developed is that there is a “front burner” (which has stories/tasks for the current sprint), a “back burner” (which has stories for the next sprint), and a “fridge” (which has stories for later, as well as process changes). One can look at a product as having been broken down like this: product -> features -> stories -> tasks.

Often effort estimations are done using “story points” (tiny = 1 SP, small = 2 SP, medium = 4 SP, large = 8 SP, big = 16+ SP, unknown = ? SP) Stories can be of various types. User stories are very common and are descriptions of what the user can do and what happens as a result of different actions from a given starting point. Other types of stories are from these areas: analysis, development, QA, documentation, installation, localization, and training.

Planning meetings for each sprint require participation by the product owner, the Scrum Master, and the development team. In the planning meeting, they set the goals for the upcoming sprint and select a subset of the product backlog (proposed stories) to work on. The development team decomposes stories to tasks and estimates them. The development team and product owner do final negotiations to determine the backlog for the following sprint.

The Scrum methodology uses metrics to help with future planning and tracking of progress; for example, “burn down” – the number of hours remaining in the sprint versus the time in days; “velocity” – essentially, the amount of effort the team expends. (After approximately three sprints with the same team, one can get a feel for what the team can do going forward.)

Some caveats about using Scrum methodology: 1) You need committed, mature developers; 2) You still need to do major requirements definition, some analysis, architecture definition, and definition of roles and terms up front or early; 3) You need commitment from the company and the product owner; and 4) It is best for products that require frequent new releases or updates, and less effective for large, totally new products that will not allow for frequent upgrades once they are released.

The Project Management Office

Many large and even medium-sized organizations have created a department to oversee and support projects throughout the organization. This is an attempt to reduce the high numbers of failed projects (see the Project Management Overview chapter.) These offices are usually called the project management office or PMO.

The PMO may be the home of all the project managers in an organization, or it may simply be a resource for all project managers, who report to their line areas.

Typical objectives of a PMO are:

• Help ensure that projects are aligned with organizational objectives
• Provide templates and procedures for use by project managers
• Provide training and mentorship
• Provide facilitation
• Stay abreast of the latest trends in project management
• Serve as a repository for project reports and lessons learned

The existence and role of PMOs tends to be somewhat fluid. If a PMO is created, and greater success is not experienced in organizational projects, the PMO is at risk of being disbanded as a cost-saving measure. If an organization in which you are a project manager or a project team member has a PMO, try to make good use of the resources available. If you are employed as a resource person in a PMO, remember that your role is not to get in the way and create red tape, but to enable and enhance the success of project managers and projects within the organization.

---

Source: Adrienne Watt, https://opentextbc.ca/projectmanagement/chapter/chapter-2-what-is-a-project-project-management/
This work is licensed under a Creative Commons Attribution 4.0 License.