Chapter One

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).

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.

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.

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.

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".

"Petrobras has established new global benchmarks for the generation of exceptional shareholdes wealth through an
aggressive and innovative program of cost cutting on its P36 production facility".

"Conventional constraints have been successfully challenged and replaced with new paradigms appropriate to the
globalized corporate marketplace".

"Elimination of these unnecessary straitjackets has empowered the project's suppliers and contractors to propose highly
economical solutions, with the win-win bonus of enhanced profitability margins for themselves".

"The P36 platform shows the shape of things to come in the unregulated global market economy of the 21st century".

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

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. 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 certaintype 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 of work.

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

Project Management Expertise

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.

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.

Project Management Expertise

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.

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 they have 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.

Project managers in multicultural projects must appreciate the cultural 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.

Project Management Expertise

Management Knowledge and Skills

As the project manager, you have to rely on your project management knowledge and your general management 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 risks 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.

Project Management Expertise

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 we're 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.

All projects require sound communication plans, but not all projects will have the same types of communication 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.

1.2
Competitive Advantage
In a competitive environment, businesses try to stand out from their competitors. Consider the following car
companies. Is there a particular characteristic or quality that you associate with each of them?

Porsche ,Volvo,Hyundai,Toyota,Ford

Companies try very hard to create a perception that they are different from their competitors. If you are looking
for a high-performance sports car you probably won't go to a Ford dealer. But if you are looking for a durable
truck you wouldn't go to a Porsche dealer. Companies strive to provide a product or service that is distinct, or
differentiated, in some way from their competitors. When customers perceive the distinction as being valuable,
they will prefer to purchase the business's product over a competitor's products. This is called a competitive
advantage. Competitive advantage means that the business outperforms its rivals in the market because
customers prefer its products or services.

Businesses can achieve competitive advantages in a number of different ways. Their product may provide
superior performance; it may be of higher quality; it may be more durable; or it may have unique features. The
businesses may provide better customer service or have better availability. They may advertise and promote
their products better, or they may offer their products at a lower price. The best businesses provide a
combination of unique attributes that competitors cannot match.

Competitive Advantage

Creating Competitive Advantage

Businesses create competitive advantage by doing some things better than their competitors. For example, look
at the companies in the chart that follows. By doing some things much better than competitors, the businesses
are able to create a valuable distinction for customers.

Creating Competitive Advantage

Company How Company Creates Distinction

Apple Research and development: creates new or improved products with leading-edge technology

Nike Marketing: uses celebrity endorsements to create a powerful brand image

Walmart Supply chain management: created a highly integrated system to keep supplier costs low and
keep products that customers buy on the shelf

ZapposCustomer service: strives to deliver "Wow!" in the customer's experience

UPS Logistics: integrates package delivery with customer needs

Zara Rapid responsiveness: quickly gets the latest styles into stores
It may seem that the best way to create competitive advantage is to do everything well. Unfortunately, this is
not possible. Generally, resources are limited and it would be much too costly to try to excel at everything.
Businesses that try to do too many things well often don't succeed at doing anything extremely well and don't
produce distinction. This is referred to as being "stuck in the middle".

Creating competitive advantage is not the only goal of business. Companies also must be able to maintain their
competitive advantage. When competitors see a company is doing something that customers value, they will try
to copy it. Some things can be copied quickly. For example, when American Airlines introduced the
AAdvantage frequent flier program to reward loyal customers, it was copied within months by Delta, United,
and British Airways. Other things are more difficult to copy. Walmart, for example, has created a tightly linked
supply chain to provide low costs. No other company has figured out how to duplicate this system. The goal of
companies is to create competitive advantage in ways that are difficult or costly for competitors to copy. This is
called a sustainable competitive advantage.

Competitive Advantage

Strategy and Competitive Advantage

Achieving competitive advantage is not likely to be a formal goal of a business. However, having competitive
advantage means a company will have resources to pursue its goals. When firms beat their competitors it means
they can finance more research and development to improve their products or services; they can spend more on
advertising and promotions to attract customers; they can donate to charities to improve community relations;
and they can provide greater profits to their owners. In short, competitive advantage is the means to meeting
organizational goals.

Because strategy is a plan to achieve long-term goals, we can define strategy as a plan to create sustainable
competitive advantage.

Walmart's supply chain helps to keep its prices low, giving it a competitive advantage over others.

The Value Proposition

Companies strive to produce a unique product or service that will give them an advantage in the marketplace.
But this produces competitive advantage only if customers perceive the difference and understand why this
difference matters to them. A value proposition is a statement that a company uses to convince customers that
its product or service provides more value to them than a competitor's product or service. The value proposition
communicates to the customer the main reason a product or service is the one best suited to their needs.

The value proposition is communicated through a company's webpage, advertising, or social media. It should
have a bold headline or graphic that grabs attention and depicts the benefits delivered to the customer. This brief
"announcement" can be followed by a short paragraph or a few bullet points that list the key features of the
product.

An excellent example is the value statement for the Apple MacBook. It shows an edge-on image of a MacBook
with the caption "MacBook: Light. Years ahead". This very cleverly conveys the important distinctions of the
MacBook. First, it's a really slick design. In the edge-on view the computer almost disappears. Second, it is
light. In the laptop market, weight is important. Both the image and the statement emphasize that the MacBook
is easy to carry around. Finally, it emphasizes MacBook's advanced technology, "Light years ahead". In a very
small space, Apple conveys the main differentiators for the MacBook – its weight and its advanced technology.
Strategic Management

Strategic management is the process of integrating all the functions and activities in an organization into a
coherent whole. We previously defined management as the process of planning, organizing, leading, and
controlling people in the organization to effectively use resources to meet organizational goals. Strategy
management provides the "glue" that holds these processes together. Rather than looking at individual functions
or activities, strategic management considers the entire organization and how the pieces fit together. Good
strategic management allows an organization to develop synergy. That is, the pieces support each other so that
the total output is greater than the sum of the output of individual functions.

Strategic management best fits with the planning function, and it involves two broad functions. The first is to
determine how the company will create competitive advantage. That is, how will the company produce
distinction and value to its customers? The answer to this question is the company's business strategy.
Management must make sure that all activities in the company support its business strategy. This is called
"doing the right things". It means everyone must be focused on excelling at the things that create competitive
advantage, making sure that resources are allocated to the departments that create competitive advantage, and
closely controlling the activities that create competitive advantage. That doesn't mean they can ignore other
things; successful businesses have to do many things well but excel at only a few.

Strategic management's second function is to make sure that the people in the organization support the strategy.
As we discussed previously, almost everything an organization accomplishes is achieved by people doing
things. Management must make sure that the people in the organization are willing and capable of excelling at
the things that create competitive advantage. This is called "doing things right". They can do this by providing
training and development opportunities for employees to improve skills that support the strategy, by creating a
compensation system that rewards behaviors that support the strategy, and by implementing a supervisory
system that encourages and recognizes behaviors that support the strategy. Management can also instill a culture
of excellence throughout the organization. Organizational culture is the shared values and beliefs that guide
individual behaviors in the organization. Managers can induce a culture that supports the strategy by
communicating and modeling behaviors and values they want to see throughout the organization.

For example, when Tom's of Maine introduced a new deodorant that disappointed customers, company founder
Tom Chappell pulled the product from the market and reimbursed the customers who had purchased it. The
company lost the money it had put into developing and producing the product, as well as the reimbursement
cost. But it reinforced the core values of fairness and honesty that the company espoused, and demonstrated that
quality and customer satisfaction were the company's competitive advantage.

In another example, Southwest Airlines' management implemented the "Walk a Mile" program in which
managers and executives pitch in to help front-line employees. Executives clean planes, load luggage, and
attend gates. Flight attendants were surprised when Herb Kelleher, the company chairman, showed up to help
them provision a plane. This program reinforces the family culture at Southwest, where everyone is valued and
considered equal. It also emphasizes the company's focus on customer service by demonstrating that everyone
has to support activities that directly affect the customer.

Strategic Management

Industry Analysis
The purpose of strategic management is to create competitive advantage. But how do companies know they
have competitive advantage? In the long term, competitive advantage will lead to greater profitability. But in
the shorter term, it is difficult for companies to assess how well they are creating competitive advantage. An
industry analysis is a method for a company to assess its market position relative to its competitors. An industry
analysis is meant to help a company review various market and financial factors in its industry that affect the
business, including evaluating the competition. This analysis helps managers understand the important factors
of the marketplace and how these factors may be used to gain a competitive advantage. Industry analyses are an
important tool for companies to assess their strategy in a shorter time frame.

Because conditions in the business environment are constantly changing, industry analyses need to be done
periodically to keep up with developments. This can be a very time-consuming process and, if not done
accurately, can lead to bad strategic decisions. For this reason, managers may go to outside firms, either to
produce the analysis or to provide data for the company to complete an analysis. A number of companies exist
that maintain huge databases of information about particular industries, such as Hoovers and IBIS. These
companies have methods for gathering the data and for analyzing the data to produce reports.

1.3 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 prehistory. 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.

Source: Adrienne Watt, https://opentextbc.ca/projectmanagement/chapter/chapter-4-framework-for-project-

management-project-management/

Creative Commons License This work is licensed under a Creative Commons Attribution 4.0 License.

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 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.

Project Management Institute Overview

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

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.

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.

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.

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.

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.
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.

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.

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.

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.

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)

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,
let's look at them in a little more detail to prepare you for the chapters that follow.

Introduction to the Project Management Knowledge Areas

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.

Introduction to the Project Management Knowledge Areas

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.

Introduction to the Project Management Knowledge Areas

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.

Introduction to the Project Management Knowledge Areas

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 detailed project 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.

Introduction to the Project Management Knowledge Areas

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.

Introduction to the Project Management Knowledge Areas

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.

Introduction to the Project Management Knowledge Areas

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.

Introduction to the Project Management Knowledge Areas

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.

Introduction to the Project Management Knowledge Areas

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.

Introduction to the Project Management Knowledge Areas

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.

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

Table 4.1 Stakeholder Register

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.

What is a Project?

In project management, a project consists of a temporary endeavor undertaken to create a unique product,
service, or result. The main characteristics of a project are:

It is a temporary endeavor

It has fixed start and end dates

It is unique – no two projects are exactly the same, and it is not a routine operation

It is performed by a team of people - teams are temporary in nature. They will be dispersed at the end of the
project.

It has a defined budget.

It has a sponsor - someone who wants the project done and will guide and fight for it.

It has a defined objective/endpoint that you can measure when complete.

What is Project Management?

Application of knowledge, skills, tools, and techniques to project activities to meet project requirements.

What is a Program?
Collection of Activities executed together in such a way that the cumulative benefit is higher than when they are
executed one at a time.

What is Program Management?

Overall management of a program is not the individual management of the constituent projects in the program.
The focus is on achieving the program objectives rather than individual project progress.

What is an Operation?

An operation is also performed by people. The major difference between an operation and a project is that
operations are repetitive, whereas projects are temporary.

What are the Similarities Between a Project and an Operation?

Both are performed by people

Both have deliverables

Both have limited resources

Both are Planned, Executed, and Controlled

What are the Differences Between a Project and an Operation?

A project is temporary, whereas an operation is ongoing

Projects have temporary teams, whereas operations have permanent teams (relatively)

Each project is unique, whereas operation steps are identical

Who is a Stakeholder?

Any person or community impacted by the project execution or project outcome or by non-execution of the
project.

What is a PMO?

A PMO (Project Management Office) is an organization within an organization supporting the project
management practice within the organization. PMO will aid in:

Making available critical project management related knowledge to the projects within the organization;

Providing tools and templates for project management;

Supporting the tools and templates usage;

Making available critical resources to the projects on time.

The Project Management Office (PMO) Concept

An organization conducting several projects on an ongoing basis should consider the creation of a central
functional unit to supply project management resources and tools, develop a methodology and procedures, and
look after systems. All these resources can be regrouped in a special unit to be called one of several names
depending upon its intent and staffing. Such a unit is commonly called a Project Management Office (PMO),
Project Support Office or Project Information Office. The specific roles and responsibilities assigned to the unit
can influence the selection of its name

Depending upon its importance, there are several roles and responsibilities that can be assigned to a project
office. They can be broken into the following major categories:

Management of Project Environment;

Project Information;

Project Support.

The organization that wishes to focus primarily on the project management process will usually assign a senior
manager to lead the process. This manager, who could be a vice president or director of project management,
would assume the following responsibilities:

Ensure the Transition.

Once an organization has decided to carry out a corporate or departmental project management approach, the
complete venture should be organized as a major project. The Project Management Office (PMO) would play a
key role in leading this project.

Provide Senior Project Managers.

The PMO could be the functional organization responsible for supplying senior project managers to major
corporate initiatives involving many operational functional groups and requiring unbiased management. It
should not be, however, the PMO's responsibility to provide all project managers.

Coaching Project Teams.

The PMO could provide coaching services to project teams across the organization in both project planning and
execution. These services could be offered to divisions that are starting to run their own projects with managers
and teams who are still lacking the required project planning and management abilities. The coaching could
include: (1) planning facilitation to help the project team develop a good project plan in line with the
organization's project management methodology and procedures; (2) setting up the monitoring and control
processes; and (3) facilitating team building and conflict resolution.

Risk Assessment.

The PMO can provide two major functions for risk assessment for the organization: to have risk assessment
tools available with coaching support for project managers to be used upon request; and upon direction of the
Project Review Committee or other competent authority, conduct risk assessment against specified projects for
corporate management.
Project Post Evaluation.

The PMO could provide post evaluation of selected projects if desired by the organization.

Career Development.

In cooperation with the Human Resources Branch, the PMO could take the lead in defining the career paths and
training requirements for the project management field within the organization. This task should include:

The development of job categories and descriptions;

The selection of personnel to enter the project management field;

The development of a training curriculum for project management; and

The development and delivery of training materials.

What is Project Portfolio Management?

Project portfolio management is all about choosing the right projects to execute that align with the
organizational strategy and will give the organization the maximum return on investment. The projects to
execute are determined by techniques such as:

NPV – net present value of investments;

ROI – Return on investments;

Payback period;

Opportunity cost, etc.

What are the Different Types of Organizational structures? How Do They Impact PM Role?

Functional Organizations

Functional organization is the most common form of organization. The organization is grouped by area of
specialization within different functional areas (sales, manufacturing, purchase, quality control, etc.). In a
functional organization, maximum power rests with the functional manager, and the project manager's role in
decision-making is minimal. Project managers play a coordinator/facilitator role. Control over the team by the
project manager is minimal.

Advantages of a functional organization; In a projectized organization, the team gets dismantled once the
project is over, hence the ownership of the career path of the project team members are not fully owned by any.
This can be the situation in matrix organizations too since there are two bosses. Whereas in a typical functional
organization, the team member's career progression is fully owned by the functional manager.
Team members report to only one boss, avoiding conflict of interest. Easier management of specialists. Fully
under the control of the functional manager. Similar resources are centralized, hence better synergy within
groups.

Disadvantages of a functional organization;

Preference for functional specialization, at the cost of the project;

No career path in project management;

Project manager has no authority.

Projectized Organizations

In a projectized organization, all the work is considered as a project (construction companies, software project
organizations). The project manager has total control over the projects. Personnel are assigned to and report to a
project manager.

In the projectized organization approach, all project staff report to the project manager or someone within the
project team structure. The staff is either seconded or hired/contracted specifically for the project and will
remain on the team as long as required. In a pure projectized organization, the project receives all necessary
staff, including administrative support. On a larger project, the projectized organization has the appearance of a
small company in that it is a self-contained unit with all the resources necessary to do the job. It is the ideal
situation for a project manager.

Advantages of a projectized organization:

Team members will be more committed to the project;

Availability of career paths within the project management stream;

More effective project related communication.

Disadvantages of projectized organization:

When the project gets over, the team gets dismantled; hence a lack of security leading short-term commitments;

Duplication of facilities and job functions eg:- administrative officer for each project, HR coordinator for each
project, seating arrangements for each project, team outings for each project, etc.;

Less efficient use of resources. Project teams tend to hang on to resources both material and human, even after
the need for them. (Some project managers take pride in their team size or develop fear when the team size
shrinks).

Matrix Organizations

Matrix organization is a hybrid of both functional and projectized organization, trying to leverage the strength
of both. The team members report to two bosses, the project manager and the functional manager.

In a strong matrix, the power rests with the project manager. In a weak matrix, the power rests with the
functional manager. In a balanced matrix, the power is shared between the project manager and the functional
manager.
The structure of a matrix project organization, when used properly, can be quite effective. When misused,
however, it can be quite disastrous. The matrix is a highly complex structure from an organizational point of
view, and management must constantly work on good communications to make it work properly.

Advantages of matrix organization:

More support from functional organizations;

Maximum utilization of scarce resources since they are easily accessible to the projects.

Better horizontal and vertical communication (better than functional)

Team members have a place to go at the completion of the project.

Disadvantages of matrix organization

More than one boss for project teams can lead to conflicts between the project manager and the functional
manager;

More complex to monitor and control if it spans different locations.

What are the Roles and Responsibilities of a Project Manager?

Roles and responsibilities vary from organization to organization. The project manager is ultimately responsible
for the success of the project (cost, schedule, and quality). The other responsibilities include:

Development of a project plan;

Executing the project as per the project plan;

Maintaining the project plan;

Project tracking;

Scope management;

Risk management;

Project integration management;

People management;

Communications management;

Procurement management;

Quality management;

Causal analysis and corrective actions;

Stakeholder management.
What are the Roles and Responsibilities of a Project Sponsor?

The project sponsor's primary role is to make the needed resources available to the project. This includes:

Approval for starting the project;

Approval of the cost budgets of the project;

Approval to the product road maps, if it is a product development project;

The decision to short close the projects if the project deliverables are not viable or do not add value in changed
scenarios;

Decisions to progress into the subsequent phases; and

Decisions not to progress into the subsequent phases.

What is a Project Management Lifecycle?

Project management lifecycle differs from project lifecycles and product management lifecycles. The project
management lifecycle comprises initiation, planning, execution, and control phases. (Hint: It is easy to
remember it as IPECC) The following table depicts the project activities grouped under initiation, planning,
execution, and control (project management lifecycle).

Initiating Planning Executing Control Closing Select project, which will give maximum benefit Create scope
statement Execute the project plan Integrated change control Procurement audits Product verification Financial
closure Lessons learned Update records End of project performance reporting Formal acceptance.

What is Stakeholder Management?

Develop product description. Determine quality standards. Use a work authorization system. Cost control.
Define the responsibilities of the project manager. Risk identification, qualification, quantification, and response
planning. Manage by objectives of the project plan. Scope verification. Iterations – go back. Ensure compliance
with plans. Determine high-level resource requirements. Create other management plans: scope, schedule, cost,
quality, staffing, communications, procurement, dependency management, etc.

What is a Product Management Lifecycle?

A product management lifecycle scope is much wider than a project scope. A typical product management
lifecycle has the following phases: Idea generation. Idea validation. Feasibility. Commit. Development. Beta.
Packaging. Release.

What is the Difference between Product Management and Project Management?

Product management consists of product idea conception to final product launch and after-sales support,
whereas project management primarily focuses on the development phase. What is a project lifecycle? Logical
phases within a project. Example: Requirements, design, coding, testing, and maintenance phases in a software
project.

What is PDCA?
PDCA – By Edward Deming. Talks about Plan – Do – Check –Act cycle, which applies to any work/project.
Primarily, the work to be done is planned first, then it is performed, the outcome is checked, and then corrective
actions are taken if there are any variations from the plan. It is also known as PDSA – Plan, Do, Study and Act.
These are steps for continuous improvement.

What is MBO?

MBO stands for management by objectives. Again MBO can be visualized from the PDCA angle. In MBO, the
objectives for performance are set first, then the team performs to meet the objectives, the progress is checked,
and corrective actions are taken if necessary. What is management by projects? Some organizations perform all
their work as projects. For example, construction companies or application software development companies.
When an organization performs all its work as projects, it is called management by projects.

What is the Difference between Leading and Managing?

Managing is primarily concerned with consistently producing key results expected by key stakeholders, whereas
leading involves establishing direction, aligning people, and motivating and inspiring.

What is the Difference between a Project Plan and a Project Schedule?

The project schedule is part of the project plan. Apart from the project schedule, a typical project plan has
scope, risk management plan, schedule management plan, communications plan, procurement plan, team
structure, tracking mechanisms, assumptions, dependencies, major milestones, etc.

What is a Project Size Estimate?

In every engineering discipline, the size of the work to be performed is estimated first before developing a cost
budget.

Examples of size budgets: Building – 2000 sq ft, Ship – tonnes, Software – Lines of code or function points.

What is a Project Effort Estimate?

Once the size estimates are arrived at, they are converted into effort estimates by applying the productivity
factor. E.g.: If a wall of 2000 sq ft size is to be built and if the productivity of the mason/day is 200 sq ft, then
the effort required to construct the wall is 2000/200 = 10 person days.

Source: Wikibooks, https://en.wikibooks.org/wiki/Project_Management/FAQs

Creative Commons License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0
License.

1.4
Important part in each of these reasons.

It is a sad fact that many projects, particularly those involving information systems, fail to deliver against their
objectives on time and within budget.
Projects fail when they are not managed well – when planning is not rigorous (or ignored altogether), when
insufficient control is exercised, when the necessary skills are missing and when elements or people are ignored
or forgotten.

A common scenario arises where miscommunication of requirements, resources and timescales result from poor
management, planning and control such as the tongue-in-cheek example depicted here.

This may look extreme, but of course whilst the image of the car may have been in the user's mind, what was
actually asked for was 'something with wheels that I can move stuff about in'…

Common reasons for project failure

Poor project specification

Unrealistic timescales

Timescales that are too long

Inappropriate staff

Insufficient involvement by senior management

Failure to manage user expectations

Failure to manage the change required

Hopefully this set of resources will help to ensure your projects are a success.

UNIT TWO : The Project Life Style

2.1 Project Managment Life Cycle
Physics tells us that light is both particle and wave. Project management has a similarly dual nature; it is both a
series of distinct phases with a clear beginning and end, and a continuous, circular process in which each ending
leads to a new beginning. Throughout a project, a successful project manager strives to anticipate changing
conditions, rather than simply responding to them as they arise.

Let's start with the more traditional view, which describes project management as a series of sequential phases,
with project initiation coming right after project selection. You can think of these phases, shown in Figure 3-1,
as the particle nature of project management.
But while project initiation marks the official beginning of a project, doing it well also requires looking past the making
stage to the entire life cycle of the project's end result. You can think of this as the wave nature of project management. As
illustrated in Figure 3-2, the making stage, in which a project is initiated and executed, is one part of the larger cycle that
includes the operating/using/changing stage, in which the customer makes use of the project; and the demolishing stage,
when the project is retired so it can be replaced by something new and better.

. Taking this holistic, life-cycle view will encourage you to ask better questions about what "success" really
means for your project. For example, as sustainability becomes an ever-present engineering concern, project
managers often need to factor in long-term environmental effects when judging a project's success. This entails
the use of tools like life cycle assessments (LCA) for evaluating the "potential environmental impacts of a
product, material, process, or activity" and for "assessing a range of environmental impacts across the full life
cycle of a product system, from materials acquisition to manufacturing, use, and final disposition". (United
States Environmental Protection Agency n.d.).

An LCA analysis early in the initiation phase can help to broaden your view of the potential effects of a project
and to increase the range of options you consider as you set the project in motion. In the construction industry,
LCAs often focus on energy and water use of a building's life cycle. In product development, LCAs are used to
assess the impacts of raw materials processing, production, packaging, and recycling, among other things. For
an interesting example of an apparel industry analysis.

An LCA is just one of many ways to kick-start the knowledge acquisition process that unfolds throughout a
project. It's not unusual to know little to nothing about a project at the start. By the time you finish, you know
everything you wished you knew at the beginning, and you have acquired knowledge that you can carry forward
to new projects. Anything you learn about a project is important, but the information you compile during
initiation sets you up to respond to the living order uncertainty that will inevitably arise as the project unfolds. It
can encourage you to look past the initiation phase to the project's entire life cycle, and then to circle back using
your new knowledge to take a more holistic approach to project initiation.

One of the best ways to learn about a project is to talk to everyone involved:

 Engage with the customer to learn all you can about what they want out of the project
over the long term. In other words, find out how the customer defines the project's value.
Be prepared to ask lots of questions. In some situations, it might be helpful to watch the
customer use a product to get a better idea of unmet needs. Keep in mind that customers
don't always know exactly what they want, and it may not have occurred to them that
they can shape their thinking around the project's life cycle. They might need the help of
an informed, experienced, sensitive project manager to formulate their goals.
 Think broadly about who the customer is and include the needs of the end user - the
ultimate customer - in your thinking. For example, if you are building a new clinic, don't
confine yourself to the executives of the HMO paying for the building. Take time to talk
to the people who will really be using the building - doctors, nurses, technicians,
administrative staff, maintenance workers, and patients.
 Talk to stakeholders - the people who will be affected by or who can affect the project -
and ask about their concerns and needs. Make sure you understand their basic
assumptions.
 As when identifying customers, think broadly about who the stakeholders are. The
customer and end users are clearly stakeholders, as is the manager sponsoring the project,
and the project team members. But don't forget about vendors, resource owners,
government officials and regulatory bodies, and members of other departments in your
organization.

Making these conversations and analyses of needs a priority will give you a broader view of your project's
overall life cycle. Though of course, in the day-to-day running of a project, you can't spend every minute
looking ahead, you do have to pay attention to the traditional phases of project management, focusing on details
like schedules and personnel. Even so, as you complete the tasks related to one phase, you often need to be
thinking ahead to tasks related to a subsequent phase. Significant overlap between the various phases is
common, as shown in Figure 3-3. You will often need to look back at and revise the information you compiled
during the initiation phase as you learn more about the project.
Figure 3-3: Even in the traditional view of project management, the phases of a project often overlap
Remember, a project is a learning acquisition activity. In most cases, what you know during project initiation is
only a small fraction of what you will know when the project is finished. You have to be prepared to adapt as
you learn more about your project.

2.2 Initiation Phase

The Work of Initiation

During initiation you will typically create the first draft of the following items, which take a high-level view of
the project:

 project charter: A "single, consolidated source of information" for project initiation and
planning. It describes your current knowledge about the project and includes information such as
the names of all stakeholders, a statement of your organization's needs, the history leading up to
the project, the project's purpose, deliverables, and roles and responsibilities. A project charter is
also sometimes called a project overview statement. It may be helpful to think of the project
charter as a contract between the project team and the project sponsors.
 scope statement: A document that defines the project's scope. Defining scope, which is really
the heart of the initiation phase, is discussed in detail in the next section.
 business case: An "argument, usually documented, that is intended to convince a decision maker
to approve some kind of action. As a rule, a business case has to articulate a clear path to an
attractive return on investment (ROI). At its simplest, a business case could be a spoken
suggestion…. For more complex issues, a business case should be presented in a carefully
constructed document. A business case document should examine benefits and risks involved
with both taking the action and, conversely, not taking the action. The conclusion should be a
compelling argument for implementation". A business case addresses these fundamental
 questions: 1) Why this project? 2) Why this project over another project? and 3) Why this project
now?

Both the project charter and the scope statement typically evolve as the project unfolds and you learn more
about the project details in the planning phase. This means that as you work through the initiation phase, you
should always be thinking ahead to the following elements of the planning phase:

 work breakdown structure (WBS): A description of the tasks associated with project
deliverables, often in the form of a tree diagram. A work breakdown structure "displays the
relationship of each task to the other tasks, to the whole and the end product (goal or objective).
It shows the allocation of responsibility and identifies resources required and time available at
each stage for project monitoring and management".
 organizational breakdown structure (OBS): A description of the project team. It explains
"who reports to whom, the details of the hierarchy, and the reporting structure…. Organizational
breakdown structures are normally communicated visually through the use of graphs or charts. A
project or general manager is listed and underneath the PM several divisions might be created,
such as product development, design, materials management, and production".
 work package: A "group of related tasks within a project. Because they look like projects
themselves, they are often thought of as sub-projects within a larger project. Work packages are
the smallest unit of work that a project can be broken down to when creating your Work
Breakdown Structure (WBS)".
 responsibility assignment matrix (RAM): A type of organizational breakdown structure in the
form of a grid that typically lists project tasks in the first column and stakeholders across the top
row, with tasks assigned to the various stakeholders. You can use it to determine if you have
enough resources for a project, and to record who is responsible for what. RAMs come in several
forms, but one of the most useful is a responsible, accountable, consult, and inform (RACI)
chart, which designates each stakeholder's relationship to each task, using the following
categories: responsible (actually does the work), accountable (has final authority over the
activity), consulted (available to provide information about the activity), or informed (is
informed after the activity is completed, often because his or her own work depends on it). (A
RACI chart is sometimes also referred to as a linear responsibility chart).

Business Case
The business case is the central document to a project or programme life cycle. The reason for defining a life
cycle with phases, tranches and/or stages is to enable go/no go decisions to be made that prevent wasted
investment.

These decisions are primarily made based on the viability of the business case.

Background
 This initial section will explain the context of the project or programme. Any assumptions made in
preparing the business case will be documented here along with constraints and dependencies on other
projects or programmes. Any impact that this work will have on other projects or programmes should
also be noted.

Project or programme summary

 All aspects of project or programme delivery will be summarised at a sufficient level to enable the justification for
the work to be understood.
 The summary will typically comprise:
o Scope – summary of objectives, in terms of outputs, outcomes and benefits as appropriate;
 o Schedule – high level schedule with start and finish dates for major sections of work such as phases,
tranches, stages or projects within a programme;
o Finance – funding arrangements and a summary cash flow;
o Risk - Major risk events and the overall risk profile;
o Resource – sources of resource, contract arrangements, summary volumes;
o Change – breadth and depth of change required;
o Stakeholders – key supporters and opponents.

Justification

 This is the key section. It weighs the benefits of the work against the investment needed to achieve them. In this
context the terms benefits and investment can be broadly interpreted.
 The simplest justification will be purely financial. If the benefits have a certain cash value and the investment cost
is less, then the work can be justified.
 However, justification is often not that simple. A project or programme will have to balance the 'investment' in
terms of risk taken; it may need to consider ecological 'costs'; intangible benefits may need complex valuations; it
may simply be that the 'do nothing' option has unacceptable consequences.

One of the tricky parts of writing a business case is where to place all the information. For example, should:

 An assumed constraint be placed in assumptions or constraints?

 An uncertainty about funding be placed in the finance or risk section?
 A reference to another project that affects the benefits be placed in dependencies or the change section?

In the outline business case it doesn't matter too much as long as all the information is in there somewhere.
When it comes to the full business case, the document is summarising other more detailed documents. The
allocation of information in the business case must therefore reflect those detailed documents. For example,
anything derived from the risk register should be summarised in the risk section of the business case and so on.

How to Illustrate Business Case Benefits

Visuals in project work

Building on the cognitive benefits of visuals presented, this chapter presents the specific case for the potential
benefits of visuals in project management. Project work has been described as a social and political process.
This challenging context requires the various stakeholders to make sense of the project world and to be in
(sufficient) agreement to make decisions and move the project towards its objectives. Visuals can support this
sensemaking process and this chapter introduces the historical foundations of the use of visuals in project work
and then discusses recent studies that make a case for the use of visuals in project work. It concludes with
reflections from project managers and executives on why visuals are particularly powerful in project work and
the enablers required for project managers to communicate visually.

Sensemaking in project work

Many project practitioners expel significant effort in dealing with the sociopolitical complexity of project work.
The concept of sensemaking can help us understand this complexity. Sensemaking is the process by which we
derive the story, or make sense of a situation, based on various cues. The project environment, like all
organisational environments, is replete with various sources of information (cues), and the possible
interpretations of these cues is potentially as numerous as the number of stakeholders receiving the information.
Much of the project manager's day can be spent trying to bring the various stakeholders, including project
teams, project boards and other influential groups and individuals into alignment in terms of making sense of
these cues and driving effort in the required direction. Given the potential cognitive benefits of visuals, it is
unsurprising that visuals are commonly seen as a tool to support sensemaking, which often leads to decision-
making in project work.

Appreciating the process of sensemaking, and its importance in project work, is foundational to the
development of effective visuals. Visuals, when appreciated through the sensemaking lens, have the purpose of
assisting stakeholders to make sense of information to derive a story (or picture) of a particular facet of the
project. Preparing effective visuals therefore relies on both understanding who will consume the information –
and their preferences and priorities – and also understanding the various pieces of data and how they relate.

Visuals as 'boundary objects'

The origins of the research on visuals in project management is found in the concept of boundary objects.
Boundary objects are abstract or concrete artefacts – for example, plans and models in construction work, a
project schedule, stakeholder matrix, or a list of project requirements – that meet the informational needs of
various social worlds, and they are often visual in nature. Researchers have found that boundary objects can
support negotiation, facilitate collaboration and conflict resolution. Whilst boundary objects are commonly
characterised as being 'stable' (unchanging), some researchers note that the very adaptability and potential
evolution of such objects can help to move forward conversations and evolve knowledge in the project context:
the visuals have agency.

Relating this concept of visuals having agency (power) in the project environment to the sensemaking processes
it becomes evident that those who craft visuals exert significant influence on the sensemaking process.
Returning to the term 'boundary object', visuals mediate between source information and those who are
interpreting the information. It reminds us of the care to be taken when developing visuals and the way we as
project managers creating visuals influence the sensemaking processes.

Concept exploration: Gantt charts

For many people, the Gantt chart is a visual that is synonymous with project management, but did you know
that the Gantt chart, and more precisely its predecessor the Harmonograph is synonymous with scientific
management and operational work?
There is now increasing recognition that our connection of the Gantt chart with project management is
problematic. The Gantt chart presents project work as being predictable and linear, as if it were 'operational'.
This has the tendency to set unrealistic stakeholder expectations regarding the way the work will unfold and can
be managed.

Research studies find that some project managers are aware of this conundrum and recognise that its worth is
not necessarily in managing the work, but rather as a tool for helping build the confidence of stakeholders, or to
meet their expectations of what project management entails.

Even though project managers may feel frustration that they are expected, or perhaps even forced to use Gantt
charts, they also manipulate this situation to their advantage and use Gantt charts to placate senior management
and clients (or use high-level versions of a Gantt chart, for example, Archetype 4). As one project manager
expressed, 'It's the Gantt charts that keeps my manager out of my office so I can get on with my work'.

This does not mean that visuals don't have a place in scheduling and managing completion of activities within
an initiative. Quite the opposite. Agile methodologies use Kanban-style boards as a central coordinating and
tracking device to manage the team's workflow, in the short to medium term. When used, for example, as part
of the Scrum methodology, they are a visual tool that forms part of a broader system for holding team members
accountable. For those interested in this style of work coordination there are several software options available
including:

 Kanban
 Trello
 Atlassian (Jira)
To summarise, when creating visuals we are deliberately or inadvertently communicating messages about a
situation or choice through our design choices. For the Gantt chart, the neat lines, running from left to right in
parallel rows down the page infer structure and order. It's no wonder the Gantt chart is seen as a tool to build
stakeholder confidence, even if it doesn't directly enable project managers run their projects, and perhaps bends
the truth of how the project will actually unfold. In the case of the Kanban board, attention is drawn to whether
tasks on the board are moving at the expected rate, as agreed between members of the project team. Visual
language is powerful, and we need to be careful about the subtle inferences that can result from our
visualisations.

Examples of using visuals in project work

Research on the use of visuals in management is still in its infancy. However, there are an increasing number of
studies that discuss the benefits of visuals in project work. The first discussed here is an example of a
contemporary project management tool, the project-space model, that is used to support sensemaking on project
status. The second example explores the use of visualised dashboards and maps in project portfolio management
(PPM).

Discussing status with the project-space model

The project-space model (refer to Figure 3.1) has its theoretical foundations in Kurt Lewin's force field analysis
which in simple terms, characterises action as being the result of competing forces (factors): a situation changes
because one force is greater than other(s). The project-space model maps, in a visual manner, the current and
potential enablers and constraints to a project's progress (van der Hoorn, 2016b). The enablers and opportunities
are factors that are currently or could potentially drive the project forward. Whereas constraints and threats are
factors that are currently or could potentially hinder project progress.

Figure 3.1: Project-space model

Note: A higher resolution file of the project-space model is also available.

Findings of an action research study of a large in-flight project revealed that the project-space model supported
strategic and integrated sensemaking of project status at project board meetings. Prior to the introduction of the
project-space model the board had used traditional dashboard reporting and other text-based reports to discuss
project status at its board meeting. Following use of the project-space model, project board members and the
project manager reported that they felt better able to discuss the most pertinent factors influencing status in an
integrated manner. Through the scaled icons representing enablers, constraints, opportunities and threats the
most influential cues were given attention during board discussions.

To summarise, in moving beyond traditional text-based reports and leveraging the design opportunities that
visuals present, the project manager felt better able to communicate the project's status and the project board
perceived that their collective sensemaking capabilities were enhanced.

Visualised dashboards and maps in portfolio decision-making

The use of visuals in project portfolio decision-making was subject to a Project Management Institute (PMI)
and University College London (UCL) funded research project. PPM is argued to be an important domain for
the application of visuals in project communication given the complexity of decision-making related to
portfolios. For example, PPM decision-making needs to take into account interdependencies between projects,
uncertainty and unavailability of information related to projects, and the sociopolitical complexity of joint
decision-making processes. Well-designed visuals are found to support decision-makers in managing this
difficult decision-making context.

The PMI and UCL research project aimed to answer the question: 'how to use and design visuals to support
cognition of data in portfolio decisions?'. The study was executed with 204 student participants who were asked
to make PPM decisions using various dashboards. The dashboards had varying degrees of incorporation of the
principles that the researchers hypothesised would support PPM decision-making: (1) interactivity, (2)
purposefulness, and (3) truthfulness, efficiency and aesthetic (refer to Figure 3.2).

Figure 3.2: Geraldi & Arlt (2015) Study Design with Four Dashboards

Evidencing the benefits of using well-designed visuals to support decision-making, Geraldi & Arlt's (2015)
study found that:
  adhering to the hypothesis design principles – particularly interactivity and purposefulness – leads to improved
cognition
 the design of visuals needs to take into account the various perspectives that may be required to inform the
decision-making
 consumers of visuals become familiar with particular visuals – be cautious (and incremental) when changing
visuals and introducing new visuals.

A specific example of a visual in project portfolio decision-making with established benefit is the visual project
map. A key strength of this visual is the representation of dependencies between projects. The ability to identify
dependencies is central to portfolio decision-making and the visual project map exemplifies the benefits that
visual representation can provide compared to narratives (or even tables). The visual project map is particularly
useful in enabling decisionmakers to see the connections between initiatives and how the decision to include a
project within a portfolio needs to be undertaken with reference to the other initiatives upon which it depends
and for which its deliverables are a pre-requisite.

The project managers' and executives' perspective on visuals

Senior managers or executives have a powerful influence on the sensemaking that arises from a set of cues. The
two research studies presented above provide evidence of the benefits of using visuals in project work.
However, recent research reveals the situational factors (the why) that make visuals particularly useful for
engaging executives in project work. The study also derived a list of enablers that are necessary for project
managers to be able to create visuals that are valued by senior managers and executives in project work.

In interviewing executives with experience in project work, van der Hoorn (2020) reveals that these key
stakeholders are subject to a variety of dispositions or conditions that make visuals a useful tool to support their
sensemaking and subsequent decision-making. For example, many executives reported that they may be
required to provide direction/decisions for a project that is not within their primary area of expertise. As such,
visuals can support them to understand new concepts and ideas with speed. Similarly, the majority of executives
comment that they are under continuous time pressure in an environment of information overload, and they
require information presented in a way that enables them to reach decisions quickly. Interviewed executives
also reported benefits in the way that visuals supported them to onward communicate key messages relating to
the project. Having a visual to take to a meeting with their senior colleagues or external stakeholders enabled
them to more accurately share the story that needed to be communicated.

While these conditions facing executives influenced their desire for project managers to use visuals, the
interviewees broadly agreed that the ability to visualise information was not a widespread project management
competency, and many project managers did not necessarily appreciate the executives' information needs. The
interviewed project managers concurred and identified various enablers and hindrances to creating visuals that
meet the needs of their executives. For example, skills in visualising are not commonly taught as part of project
management education and this effects project managers' confidence to visualise. Project managers also
perceive that they are hindered by their organisations not providing the necessary software to create visuals nor
direction on any standards for creating visuals. The interviewees noted information challenges that while not
only relevant to visual communication are pertinent in creating truthful visuals. Sometimes it is not possible to
get accurate or current data, and there are occasions where project managers feel being honest would have
adverse repercussions.

This study highlights that whilst many executives will be disposed to appreciating visuals, many project
managers feel ill-equipped or unsupported to communicate using visuals.
Chapter 3 summary

 Sensemaking is the process of creating meaning from various cues in an environment about a situation – it is a
key activity in project work
 Visuals can be described as boundary objects – a term used for artefacts that meet the information needs of
various social worlds and can support sensemaking
 Research studies are increasingly reporting the benefits that visuals provide to support project work
 A number of conditions dispose executives to preferring visualised communication
 Project managers require various supports to enable them to be able to effectively create visuals that meet the
needs of their stakeholders