0% found this document useful (0 votes)
8 views14 pages

UNIT-2 PM

Uploaded by

2103a51237
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views14 pages

UNIT-2 PM

Uploaded by

2103a51237
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

UNIT-2

Project Structures

Companies set up three types of structures in which to execute projects: Functional, Matrix, and
Projectized. Each structure has different strengths and weaknesses. Rarely does the project manager get
to choose the company structure, so it is important to understand the role of projects in the
organization, and the challenges that will arise.

Functional Organizations

Departments, which have a specific mission, dominate a functional organization and the power of the
project manager is weak. When a project arises, a team is assembled from the departments. Once the
project is over, the team members return to their home departments. The managers of the departments
are referred to as functional managers.The functional approach is common in small organizations that
do not want to create an expensiveproject structure. Management is handled through normal
departmental channels.

The advantages and disadvantages of performing projects in functional organizations.

An example of a functional organization is a university, which is organized into academic


departments. Occasionally, a project arises that needs an interdisciplinary team, e.g., hiring staff,
developing a marketing strategy, and rewriting the web site. Each of these requires expertise from
many departments, and so a committee is formed to accomplish the project. The team members meet
and work to accomplish the project, but do not leave their departments.

Matrix Organizations

The matrix structure is a hybrid in which the project team is assembled from departmental assets.There
are two chains of command: A project chain and a department (or functional) chain, and, as a result,
team members report to two managers: The project manager on project matters, and their functional
manager on technical matters. This is a source of pressure for the team members, who must keep two
bosses happy. While complex, the matrix organization gives companies the best of both worlds. Projects
get the advantage of a dedicated project manager, and a Program Management Office that invests in
projects.The company realizes the long-term benefits and efficiencies of departmental structures, which
are better at nurturing technical expertise and moving staff between projects.

Table 4.5: The advantages and disadvantages of performing projects

Matrix organizations are classified as strong, balanced, or weak, where the adjective applies to the
power of the project manager. A strong matrix behaves like a Projectized organization while a weak
matrix looks somewhat like a functional organization. The balanced matrix is the traditional form, where
the project manager is responsible for the project and the functional managers have responsibility for its
technical performance. Many large Defense Contractors are organized in a matrix structure.

The matrix structure is the most important one to understand:

• It is a powerful way of accomplishing complex projects, while simultaneously balancing the needs of
the organization and the needs of the project.

• All of the managerial, staffing, and technical issues that occur in the matrix structure also occur in the
other structures. The issues are much clearer in the matrix structure and easier to understand.

Projectized Organizations

In a projectized organization, most of a company’s work is performed in projects. Each project has its

own independent team under the leadership of a project manager, who is usually dedicated to the

project. The advantages and disadvantages of projectized organizations are summarized in Table 4.6.
Table 4.6: The advantages and disadvantages of performing

An example of a Projectized organization is a construction company. Each new building is a project, and
teams are assembled as needed. When the project is complete, the team members all move on to other
projects. That is a polite way of saying that either there is another project for the team to work on or
they are unemployed. They also hire subcontractors as needed: steel workers, plumbers, carpenters,
etc. Everyone is dedicated to the project. Another example of a projectized organization is the movie
business. The team for a movie is assembled from independent contractors: the director, scriptwriters,
actors, lighting techs, grips, etc.When the project is over, they all move on, to the next movie or
unemployment.

The Project Environment

A project manager must be aware of the external environment surrounding the project, as well as
creating a positive internal environment for the team.

The Internal Environment

The internal project environment influences team members’ attitudes and their desire to perform. For a
project to succeed, team members must be committed to the project’s goals and care about producing a
quality product or service.

A positive internal environment includes:

1. A corporate culture that acknowledges and appreciates the efforts of team members.

2. Good working relationships among team members.

3. Clear and open communications.

4. An environment of trust.

5. A willingness to take risks.


6. Recognition of efforts and achievements.

Apart from the first item, which depends on the corporate climate, these qualities are the Responsibility
of the project manager. They are important because they relate directly to the Characteristics of a
project. Since projects are unique, the project manager must ensure that everyone understands both
the objectives and their own roles. A willingness on the part of the team to take risks is required
because they are venturing into uncharted territory.

The External Environment

The external environmental influences include:

1. The parent company, including upper management.

2. Organizational assets, including policies and procedures, lessons from previous projects,etc.

3. The company culture, existing staff, and company investment in tools and technologies.

4. The political environment, including government policies, tax incentives, etc.

5. The business climate, including company strength, business strategies, and access to funds.

6. The geographical setting, including environmental issues.

7. Social commitments, including benefits and working conditions.

Deliverables

The focus of most processes and tools is the development, completion, and assessment of the
deliverables. e.g., the Work Breakdown Structure is a “deliverable-oriented hierarchy.” Further, the
entire theory of earned value depends on measuring the status of the project through the assessment of
deliverables.

⮚ Deliverables are the tangible outputs of the project.

⮚ Deliverables are tangible, meaning you can see them and touch them.

⮚ It is important to recognize that deliverables are outputs of the project.

⮚ A project begins with an end-deliverable, which is the project itself.

There are also intermediate deliverables, such as the design and deliveries of components. The project
management process results in deliverables such as documentation and managerial reports. Examples
of intermediary deliverables include:

• The Scope. This might actually consist of several, separate deliverables as the project

proceeds: Preliminary Requirements, Conceptual Design, and Detailed Design.


• Cost and Schedule Estimates. These are required at major milestones to report on the status of the
project.

• Intermediate project components. These might include early prototypes and partial project deliveries.

• Project Management Reports. These include monthly reports, containing cost and schedule data,
project status, risk updates, stakeholder issues, etc. Sometimes, items are delivered to the project, but
these are not considered to be deliverables.

For example, in a construction project, the delivery of 2x4s, paint, and cabinets are not examples of
deliverables; they are deliveries. Even if they are electronic documents, we are still going to use the
word tangible. We prefer the idea of a tangible deliverable, even if it is electronic.

Measuring Deliverables

A project manager spends a lot of time and effort assessing deliverables. Every deliverable must be
checked for compliance with the scope, whether it is on-time or not, and if it is within its budget. All of
these questions hinge on some kind of assessment or measurement of the quality and acceptability of
the deliverable. Therefore, when the deliverables are proposed, the project manager must consider how
they are to be assessed and measured.Some deliverables are actually quite easy to measure. Examples
of easily measured deliverables are:

• Miles of roadway completed.

• Linear meters of steel girders erected.

• Square meters of wall painted.

• Pages of documentation written.

Small Deliverables

A deliverable should be able to be produced by one-to-two people in one-to-two weeks.Break all the
deliverables into pieces with the above rule. That way, you can manage them. Ifsomeone gets into
trouble, you will know immediately.When dividing up a deliverable, there are several things to consider:

• Small. The earlier you can tell if the deliverable is in trouble, the more options you have to fix it. Small
deliverables make this possible.

• Discrete. The more separable the deliverable is into independent units, the less interaction there is
among both the content and the staff. When building a house, one naturally divides deliverables
between the plumber, electrician, carpenter, etc. The pieces are more manageable when divided into
discrete technical sections that have little interaction.

• Manageable. Dividing the document into pieces also makes them manageable. It is easier to

determine their cost and schedule, and to track them during production.
• Parallel Development. When it comes planning, dividing the deliverables into many smaller pieces
gives the project manager the ability to work on the activities in parallel, which shortens the schedule.
Also, smaller deliverables can often be assembled in different ways,which increases flexibility, e.g., in
staff assignments.

Progressive Elaboration

Since a project has not been done before, you learn as you go and the project manager must expect
changes, which must be managed with care. The gradual evolution of the project plan is called
progressive elaboration. Progressive Elaboration is the continuous improvement and detailing of the
plan as more specific information, and more accurate estimates, become available.The progressive
detailing of the project management plan is also called rolling wave planning.

MILESTONES:

Milestones allow you to track the status of the project. For example, the completion of the scope is a

major milestone for all projects. Every milestone should have a date associated with it. During project
planning the date is the planned milestone, and after successful execution, it becomes the actual
completion date. A milestone is a significant point or event in the project.

For example, the completion of project planning is a major milestone for a project. The milestone is
marked by the completion of the Project Management Plan, and its acceptance by the customer. It is
appropriate, therefore, to create a milestone called Planning Complete when the plan is accepted by the
customer.

A milestone is also considered to be:

A milestone is an activity with zero duration.

For example, in the project, we could schedule an activity called Design Complete, and give it zero
duration (which makes it a milestone). We can then link the milestone to end of the Design activity. That
way, if the design is delayed, the completion milestone will automatically be delayed as well.

You can also create milestones for the planning events. For example, you might create a milestone
called Scope Planning Complete. The difference between the scope planning and actual completion of
the scope is useful information.

These milestone examples come from the New Kitchen project: As of June 1st:

• DemolitionComplete.Planned:March31st.ActuallycompletedMarch31st.

• Gas line installed. Planned: April 15th. Delayed by the gas company; completed May 15th.

• Cabinet Delivery. Planned: June 22nd. Not complete, on schedule.


PROJECTS AND COMPANIES

The project manager is responsible for the project. This means that project managers must do whatever
it takes to get the job done and satisfy stakeholders. What happens when these ideas conflict with the
goals or culture of the company? This is an important issue for all project managers, because in most
respects, companies and projects have completely different goals.

Both companies and projects must be successful: companies must flourish while project goals are
achieved. The trick is to balance the needs of a project with the needs of the company. The competition
between projects and companies is inherent in their structures, and the stress created on project
managers is a fundamental part of the job. If you wonder why organizations structure themselves in the
complex ways discussed below, they are trying the balance the goals of the company and the goals of
their projects.But remember, as a project manager, you are responsible. No excuses.

Projects Goals vs. Company Goals

Projects violate most of the ideas that companies consider as good management. To be specific, projects
and companies have completely different and competing goals. Project goals are almost always in direct
conflict with those of the company that sponsors it. The goal of a company is to manage efficiently,
which implies repetitive actions that can be continuously improved. The Japanese have a word for it:
kaizen.

A simple example is travel expenses: It doesn’t make any sense to allow each department to have their
own travel forms and procedures. Companies therefore, insist on a standardized, company-wide, travel
reimbursement process.

We argue that for almost all project characteristics, the goals of the project (on the left) are completely
opposite to the goals of the company (on the right).

Project Goals vs. Company Goals.


⮚ Projects are inherently interdisciplinary, while companies are organized into departments,
usually with a single expertise. Departments are good for companies because they acquire and
develop their expertise by investing in the skills of their employees, which generally enhances
the capabilities of the company. Company departments stay current by investing in technology,
staff training, etc.

⮚ On the other hand, projects are typically shortsighted because a project’s technology may be
static. Once the project team has learned enough about the technology to implement the
current project, there is no incentive on the part of the project to invest in staff growth.

⮚ In fact, projects are defined by their scope document, to which changes are actively
discouraged. Therefore, it is not unusual for the skills of people working on long-term projects to
become obsolete.

⮚ Departments are silos of expertise, and they have little or no incentive to become
interdisciplinary. In fact, this is often discouraged as it dilutes their capabilities. An accounting
department needs expertise in accounting, and doesn’t really care about environmental
regulations or web design.

⮚ On the other hand, projects are inherently interdisciplinary, and a project manager may have to
worry about accounting, environmental regulations, and web design.

The PM’s Friend: The Technical Director

The role of the project manager (PM) is to manage the customer, the money, and the schedule. While

the PM manages the deliverables’ cost and schedule, who manages their content? For example: Do the
deliverables meet customer requirements? Does the project actually work? In every project there is
always a role for a person we call the Technical Director (TD) whose job it is to manage the technical
aspects of the project.There is a natural, and inherent, tension between the PM and the TD:

Another word that describes the role of the TD is architect, in its most general sense. For example,on an
IT project, there may be an architect, whose job it is to create the design, including the human interface,
the database structures, etc.In the movie industry, we suggest that the TD is the director, who controls
the performance factors:directing, casting, camera angles, staging, lighting, etc. The producer controls
the money, the schedule, and interfaces to the studio (the customer). The producer is fulfilling the role
of the PM.What makes the movie case interesting is that it is one of the few cases where the TD often
has more power than the PM.
On most projects, conflicts often arise when major deliverables are due. The situation typically evolves
as follows: The project manager is pressing the team to meet the schedule for a major deliverable. The
technical director is resisting, explaining:

• The performance is not up to the spec.

• To meet the required performance, extra time and money is required.

• Therefore, the deliverable is going to be late.

This is really bad project management!

It is not the team’s fault, it is the fault of the project manager. A bad project manager will continue to
insist that the team deliver on time, and more forcefully as the deadline approaches. Meanwhile, the
PM assures the customer the project is on schedule and budget. First, as soon as the TD is assigned, the
project manager sets about getting to know the TD. They discuss the tasks, the budget, and the
schedule. They discuss all of the estimates, and where problems might lie.

The PM and TD jointly develop a workable project. The TD designs the approach, and the PM the cost
and schedule, but they cooperate. The project manager sells the cost and schedule to the customer. The
TD sells the product to the customer who agrees to the spec. When technical issues arise, the TD meets
with the PM and explains the problem. Together they work out the impacts and discuss options. When
cost and schedule issues arise, the PM meets with the TD and explains the problem. Together they work
out the impacts and discuss options.

PROJECT LIFE CYCLES

All projects go through natural life cycle patterns or phases. The details differ from one industry to
another, but all projects have an orderly sequence of phases and activities. We describe a few project
life cycles from various industries to illustrate the diversity of patterns.

A simple, informal way to remember the project life cycle is by what we call the A-B-C-D-E-F

stages:

Alignment: of project goals with company strategy.

Business Case: the need and reason for the project.

Charter the project: officially launch and identify the PM.

Develop the project: plan it.

Execute the project: do it.

Finish the project: close it down and learn its lessons.


Projects may have sub-projects, which also follow the same life cycle. The life cycle should seamlessly
integrate the project management functions and processes with the technical aspects of the project.

Life cycle activities include:

• Organizing: Determining the quality and quantity of resources needed and using communication skills
to obtain and manage them.

• Motivating: Creating an environment that provides satisfaction to the team members and encourages
them to do their best.

• Directing: Providing management and leadership to stakeholders and influencing them to achieve
project goals.

Products and Services Life Cycles

The Product Life Cycle begins when a product is conceived and put into development. It is then
introduced to the market,followed by a growth in sales, a sales peak, and a gradual decline. See Figure
5.1.

Figure 5.1: The product life cycle

Profits follow a different curve. There is an early investment when the product is in development, and
profits do not accrue until the product has been in the marketplace for a while. Eventually, if the
product is successful, there is a period of profitability, called the mature stage, followed by a decline,
and the product’s withdrawal from the market. The reality is complicated by many issues. Successful
products rarely exist in isolation and often evolve through product lines, which enhances their life.
Successful products engender competition and technological innovations may make products obsolete.
Also, sales are not necessarily a good measure of the product health, since they are influenced by the
economy, competitors, and customer whims. For new products and services, the development stage is
typically a project. Once the product or service is introduced to the market, it is no longer a project, as
the activities become routine: manufacturing, sales, distribution, etc. There may be occasional projects
along the way, such as a product improvement, a new advertising campaign, or the implementation of a
new supply chain.

The Project Life Cycle

Projects have their own life cycles (within the product life-cycle) with an orderly sequence of integrated
activities.3 There are three stages in the project life cycle:

1. Pre-Project Phase

Activities in the pre-project phase include recognizing a business opportunity, creating a business case,
and obtaining seed funding.The primary job of the pre-project phase is to ensure that there is a viable
project, before one invests money in it. This is referred to as requirements definition, although design
work is required to validate major technical issues. Also required at this stage are preliminary cost and
schedule estimates. Building a prototype is often an efficient way to determine feasibility, estimate the
cost and schedule, and analyze major risks. Of course, a prototype can be considered to be a separate
project.

2. Implementation Phase

During the project implementation phase, a project goes through a structured development life cycle,
where the product or service is defined, designed, built, tested, and accepted by the sponsor. The
products of this phase are the project deliverables, including the product or service itself, as well as
intermediate deliverables such as the design. Outputs from this phase also include the project
management process outputs. The deliverables in this phase are the outputs from the processes, e.g.,
The Charter is an output of the Create

3. Post-Project Phase

The post-project phase begins as soon as the product or service is commissioned and operational. The
activities in this phase are typically not part of the project, consisting of such things as manufacturing,
routine services, and maintenance activities. In some industries, the post-project phase is very
expensive. For example, the decommissioning and retirement of a nuclear plant is extensive and
rigorous, and can take several years.
Table 5.1: Example of Activities, Deliverables, and Decision Gates.

Industry Life Cycle Examples

Each industry has their own version of the project life-cycle. Because the terminology and importance of
deliverables is different, each industry has naturally evolved their own approach.

The Software Development Life Cycle

The software development life cycles consists of:

1. Definition phase: During this phase the customer’s problems are defined and the requirements
elicited. The team conducts systems analyses and develops the project plan.The deliverable is the
specification, which contains the user requirements, and a test plan to measure compliance.

2. Design phase: The software and business analysts design an acceptable solution for the customer.
The deliverable is the design document. Also, the project manager finalizes the baseline cost and
schedule.

3. Construction phase: The software is coded, and unit testing may occur here.

4. Testing phase: The product or service is tested against the specification.

5. Acceptance phase: The customer analyzes the acceptance test results and, if satisfactory signs the
acceptance agreement. Customer training may occur during this phase. The operation phase begins
after customer acceptance. The software development cycle is made up of four phases, but, depending
on the size of the project, there may be additional phases or sub-phases. Each phase and sub-phase
must have clear objectives, as well as achievable milestones and deliverables–see
The Pharmaceutical Industry Life Cycle

To contrast with the software development life cycle, we present a brief overview of a typical

pharmaceutical life cycle, which consists of:

• Research and Development: New potential drugs are identified.

• Discovery and Screening: Drugs are refined and tested.

• Pre-clinical Development: The effects on trial populations are determined.

• Clinical Trial Phase: The drug goes from laboratory sample to pilot production and, finally, to
commercial production.

• Registration Phase: Government forms and compliance documentation are completed and, hopefully,
the drug is approved.

• Post Registration Phase: Packaging and marketing occurs.

The Construction Industry Life Cycle

The key stages in the construction life cycle are:

• Apply for Permits.

• Site Work: Clear ground, install temporary power and utilities. Inspection.

• Foundation: Excavate, concrete, basement walls, waterproof and insulate. Inspection.

• Framing: Install joists, frame walls. Inspection.


• Dry In: Sheathing, roof decking, shingles, doors and windows. Inspection.

• Utilities: Plumbing, electrical, HVAC, phone, cable, computers, alarms. Inspection.

• Interior Finishing: Insulating, dry wall, paint and wallpaper, cabinets, tile and appliances.

Inspection.

• Landscaping and Groundwork: Driveway, sod, plantings. Inspection.

• Final Acceptance: Walk-through, inspection and complete punch list. Conduct final acceptance for
Certificate of Occupancy.

You might also like