| CATEGORII DOCUMENTE |
| Bulgara | Ceha slovaca | Croata | Engleza | Estona | Finlandeza | Franceza |
| Germana | Italiana | Letona | Lituaniana | Maghiara | Olandeza | Poloneza |
| Sarba | Slovena | Spaniola | Suedeza | Turca | Ucraineana |
Define the project team
Project management supports three basic levels of projects: projects, subprojects, and programs.
What Is Project Management?
People sometimes use the terms project management, project, subproject, and program without understanding their meaning. So lets first define these terms and compare their meaning. Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder objectives and expectations from a project (from PMI).
Project management supports three basic levels of projects: projects, subprojects, and programs.
A project is a temporary endeavor undertaken to produce a unique product or service.
A project is a unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective that conforms to specific requirements, including the constraints of time, cost, and resources (from ISO 10006).
Projects differ from operations, such as manufacturing, in that operations are ongoing and repetitive, while projects are temporary and unique (from PMI). Projects can range from simple efforts to large, complex undertakings that require much time, effort, and money.
Like a project, a subproject is:
The Worldwide Project Management Method (WWPMM) defines a program as a group of related projects and other activities managed in a coordinated way to achieve a common long-term objective.
What Are the Main Differences between a Program and a Project?
The main differences between a program and a project are that a program achieves a strategy or mission, is realized through multiple projects and ongoing activity, and has a scope that might be either broadly defined or specific. A project, on the other hand, has a start and a finish, achieves a single set of defined objectives, and is a tactical initiative.
What Is Project Management?
WWPMM defines project management as the application of knowledge, skills, tools, and techniques to project activities to meet or exceed stakeholder objectives and expectations from a project (from PMI). WWPMM also defines project management as the planning, organizing, monitoring, and controlling of all aspects of the project in a continuous process to achieve its objectives (from ISO 10006).
WWPMM defines work units as portions of the work to be done that have certain common properties and therefore are appropriate to group and assign to one subproject or project organizational unit. Work units are used in early definition stages to help organize and construct the work breakdown structure (WBS).
WWPMM defines the project management system as the management system for a project. It includes processes, resources, roles, and responsibilities. It is documented as a collection of plans, procedures, and records that define and support the way the management of the project operates.
The Project Management System (continued)
The project management system of a project comprises the following items:
The Project Management Knowledge Network
You would not manage a project 10 years from now the same way you would manage a project today. Just as you develop in your personal life, you should always be looking for ways to manage your projects more efficiently. One way to do this is to reuse the lessons learned from other project managers.
The Project Management Knowledge Network (PMKN) can be a useful tool for you as a project manager. It can help you in many ways, including:
You can also help other project managers learn from your experience by giving the PMKN the knowledge acquired in your projects. This supports current and future projects and also establishes your project management credentials.
Use the following steps to access ICM AssetWeb through the Knowledge portal.
More information about the PMKN is available in Module 12, 'Project Closeout.'
Managing Projects in Different Environments
Every project has a definite start and finish. Projects are usually divided into phases; the phases comprise the life cycle of the project.
Phases help you to reduce the risk on your project.
Managing Projects in Different Environments
Every project has a definite start and finish. Projects are usually divided into phases; the phases comprise the life cycle of the project.
Phases help you to reduce the risk on your project.
A customer is the recipient of a product or service provided by the delivery organization. The customer might be the ultimate consumer, user, beneficiary, or purchaser (ISO 8402). The customer might also be the sponsor.
IPD funding is approved on a phase-by-phase basis, based on a number of considerations, such as the business case and risk assessment. The key decision point is at the end of the plan phase, when the DCP contract is signed.
WWPMM. In this methodology, the IBM delivery organization can have relationships in either the IPD or the CRM business model. The cost and staffing level curve in the figure shows how resources are used in the various phases of a project. The curve shows that resource usage normally starts at a low level during the initial phase, increases quickly during the intermediate phases and then decreases during the final phase. The specific rate of increase or decrease, and the peak usage varies from project to project. However, most projects follow this curve.
The
graphic shows the phases in the life cycle of a project in the environments in
which we are most interested: Integrated Product Development (IPD), Customer
Relationship Management (CRM), WWPMM, and Project Management Body of Knowledge
(PMBOK).
The following table will explain part of the graphic:
|
Initial Phase |
Intermediate Phase |
Final Phase |
||
|
WWPMM |
Defining |
Planning |
Executing/Controlling |
Closing |
|
CRM |
Solution Design |
Solution Design |
Solution Delivery |
Solution Delivery |
|
IPD |
Concept |
Plan |
Develop Qualify Launch |
Life Cycle Close |
|
PMBOK |
Initiating |
Planning |
Executing/Controlling |
Closing |
Note: The cost and staffing level is lower at the beginning and final part of the project. And it is higher in the intermediate phase.
IPD business model. In this model, the IBM delivery organization might have a relationship with the Integrated Portfolio Management Team (IPMT), as the project sponsor, or with an external customer.
CRM business model. In this model, the IBM delivery organization has relationships with both an opportunity owner within IBM and an external customer.
Major Process Groups in PMBOK. The major process groups in PMBOK are Initiating, Planning, Executing/Controlling, and Closing. These are the groups used by PMI. The activities within these groups are similar to those in WWPMM. Both are oriented to establishing and enforcing a disciplined approach to project management that will help IBM succeed on projects.
A customer is the recipient of a product or service provided by the delivery organization. The customer might be the ultimate consumer, user, beneficiary, or purchaser (ISO 8402). The customer might also be the sponsor.
Major Phases in IPD
Major Phases in CRM
The two major phases of the CRM framework are solution design and solution delivery.
Major Process Groups in WWPMM
In WWPMM, phases are referred to as process groups. The major process groups are Defining, Planning, Executing/Controlling, and Closing the project. Depending on the project, it might be appropriate to apply all the WWPMM process groups within one individual project phase. An example would be using the Defining, Planning, Executing/Controlling, and Closing process groups were all used for one of the IPD phases.
Behaviors of a Successful Project Manager
Think about successful project mangers you have worked for in the past. What did they do that made them successful? More than likely, they possessed the following behaviors in four areas.
Team Building. A successful project manager should be sensitive to people and situations. A project manager should be able to facilitate, coach, provide constructive criticism when required, have the ability to build a team, delegate well, be sensitive to wants and needs, and offer praise when appropriate.
Roll your mouse over each team-building behavior to read its definition:
Communication. A successful project manager should be able to communicate well, be organized, have the ability to listen, think systematically, and maintain contact with all stakeholders and team members on a project.
Roll your mouse over each team-building behavior to read its definition:
Project goal setting. A successful project manager should be proactive, willing to try new ideas, able to persevere, be goal oriented, able to prioritize, be innovative, and have the ability to plan.
Roll your mouse over each team-building behavior to read its definition:
Leadership. A successful project manager should be honest; able to motivate; and be realistic, assertive, decisive, self-confident, enthusiastic, energetic, supportive, and always in pursuit of excellence.
Roll your mouse over each team-building behavior to read its definition:
The purpose of the Project Charter is to document the:
A Project Charter is a document that formalizes the request from a sponsor for responding to a business need. It is a clear statement of project intent, and it provides a preliminary delineation of roles and responsibilities. The Project Charter is issued by the sponsor, and it outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager. It serves as a reference of authority for the future of the project.
The Project Charter is an important tool for establishing the authority assigned to the project manager, especially in a matrix environment. It is considered industry best practice, and it is a defined WWPMM work product.
Project Stakeholders
You will learn later on that one of the key reasons for project failure is that stakeholders lose their commitment to the project. But who are the stakeholders, and why is it difficult to manage them?
A stakeholder in a project is any individual or organization that is actively involved in the project or whose interests might be affected, either positively or negatively, as a result of project execution or successful project completion. Identifying and communicating with the stakeholders is an important responsibility of the project manager.
There is an inherent difficulty in being caught between the sponsor and IBM. Spending all the money in the budget for a fixed-price contract might result in a happy sponsor, but might not meet IBM goals. The opposite can occur with a time-and-materials contract.
Most projects have a number of stakeholders, and they each have their own objectives to meet on the project. The project manager must be aware of each of these stakeholders and their respective objectives. Using this information, the project manager must ensure that what is done on the project is consistent first with the project requirements and then with the stakeholders' objectives. Ideally, the objectives of the different stakeholders are closely aligned. If not, a series of negotiations might be required to align the objectives.
An IBM project manager must be many things to many people. The role of the project manager is to serve as the single point of contact for all matters relating to the project and to continuously balance project scope, cost, and schedule. This must be done while interfacing with a number of people and organizations within IBM, with the customer, and with external or internal suppliers.
The Project Charter
The Project Charter is usually the first piece of documentation produced for a project. Its purpose is to make the project official and should be written by the sponsor. If a Project Charter is missing or poorly written, it can lead to ambiguity about the project objectives, scope, or solution. This could lead to project cancellation or cost and time overruns. If the Project Charter is not well-written, it is your responsibility as the Project Manager to go back to the project sponsor and help them create an adequate charter.
A Project Charter is a document that formalizes the request
from a sponsor for responding to a business need. It is a clear statement
of project intent, and it provides a preliminary delineation of roles and
responsibilities. The Project Charter is issued by the sponsor, and it
outlines the project objectives, identifies the main stakeholders, and defines
the authority of the project manager. It serves as a reference of authority for
the future of the project.
The Project Charter sets boundaries for the scope of the project. It
formally recognizes the existence of a project. It should be issued by
the project sponsor, and at a level appropriate to the needs of the
project. It provides the project manager with the authority to apply
organizational resources to project activities.
The Project Charter is usually a short document that refers to some other more detailed documents, such as a New Offering Request or a Request for Proposal.
Some project managers have never had a Project Charter, or if they did, they might have known it by some other name. Though in IPD, this document is known as the Project Charter, in CRM, it is known as the Project Definition Report. Both IPD and CRM require this document as part of the project management process. If the sponsor does not follow either process, it is good project management practice to insist upon the creation of a Project Charter. As a last resort, if you as the project manager cannot get someone in authority to write the Project Charter, it might be advantageous for you to write it and submit it to the sponsor for approval.
The Project Charter is an important tool for establishing the authority assigned to the project manager, especially in a matrix environment. It is considered industry best practice, and it is a defined WWPMM work product.
Who Creates a Project Charter
Project Charters are becoming more common in all kinds of project environments. Many organizations generate these documents in letter form. Within IPD, for example, the Project Charter is issued by the Integrated Portfolio Management Team (IPMT), which is the project sponsor. Within CRM, the Project Charter is written by the project sponsor. You need to understand the process for creating Project Charters within your business unit.
What Is the Project Definition?
A Project Definition document is a WWPMM work product that helps the project manager determine the boundaries of the project. In other words, it defines what the project will and will not encompass. WWPMM defines the Project Definition as the document that describes the shape of the project.
The Project Definition document includes the objectives and scope, the stakeholders and the proposed organization, the responsibilities, and the major risks associated with the project.
The purpose of Project Definition is to:
Framework for the WWPMM Project Definition
The following framework is for the Project Definition as
defined by the WWPMM Project Definition work product. For assistance with
creating a Project Definition, refer to the WWPMM Project Definition work
product. This can be found, along with descriptions and templates for all
WWPMM work products, at the WWPMM Portal.
Creating the Project Definition
You should create an initial version of the Project Definition
after assessing the project goals and objectives. Do this before refining
the solution to the level that is appropriate for planning. The initial
version of the Project Definition contains the objectives and the plan for the
defining activities.
To do this, you must review all existing project documentation including
documents and correspondence that have accumulated. Pay special attention
to the Project Charter as one of the primary inputs. You must also meet
with the main stakeholders identified in the charter and obtain their view of
the target solution and project scope, paying special attention to their needs,
and the risks they identify. Then, based on what you have learned, use
the WWPMM template for the Project Definition and fill in the required
information.
Worldwide Project Management Method (WWPMM) describes the way we manage projects in IBM. WWPMM is sponsored by the Project Management Center of Excellence, to support a corporate action directing us to design and implement a single, common project management method for IBM projects worldwide.
It is the project manager's responsibility to tailor the project management (PM) methods, within the constraints of the PM policy, to suit each particular project.
The WWPMM PM work product contain definitions of the 'verifiable outcomes' of implementing the processes within the method. They are organized into PM work product groups. Each work product is part of a Domain.
There are templates associated with most of the work products.
List of the templates:
Plans
Communications management plan
Deliverable definition
Financial plan
Human resource plan
Milestone list
Operational schedule
Organizational breakdown structure
Product breakdown structure
Project decision structure
Project definition
Project management schedule
Project management system summary
Project procedures description
Project quality plan
Risk definition
Risk management plan
Staff schedule
Technical environment plan
Work breakdown structure
Work product list
Records
Action control document
Action log
Asset inventory
Change log
Change order
Change request
Compliance incident document
Compliance incident log
Contact list
Correspondence log
Delivery control documentation
Event log
Expenditure log
Findings log
Individual status report
Issue document
Issue log
Meeting documentation
Project evaluation report
Project status report
Quality review documentation
Risk occurrence document
Situation analysis documentation
Staff list
Subcontractor status report
Subproject/team status report
Supplier selection report
Team charter
Technical environment assessment
Other documents
Agreement
Project charter
Projects Are Like Small Businesses
One thing that I have learned is that running a project is
like running a small business.
In both projects and small businesses, there is a fine line between being
successful and profitable,
and being unsuccessful and bankrupt. If a business fails, people will be
out of work. A business manager must ensure the business turns a profit
so it can continue serving its clients. Similarly, a project manager must
take ownership of the financial side of a project to make the project a
financial success.
Both projects and small businesses consume resources, such as staff, equipment,
and facilities.
Projects, like small businesses, have stakeholders, or people
who have an interest in the outcome of the effort. These people might
have financial interests, like the allocation of equity capital, or they might
have a stake in defining the objectives of the business or project. Most
importantly, they demand returns on capital investment or specific results.
A small business carefully tracks its costs, schedules, and quality.
Small businesses must always watch the bottom line when it comes to financial targets.
The small business owner must work within a budget and control costs. It
is imperative to a small business that it generate revenue and profit to ensure
a positive cash flow. The same tracking is a necessary part of project
management.
Benefits of a Project
Charter
I always have a Project Charter, the major benefits of a Project Charter
are that it:
Impact of Not Having a Project Charter
Lack of a Project Charter or a poorly written Project Charter often leads to an unclear need that is likely to give unstable direction to the project; possible ambiguity about the project objectives and scope; possible ambiguity concerning the solution; and possible lack of identifying an important stakeholder for the project.
These are serious concerns
that you as the project manager must ensure are properly addressed by insisting
that a sound Project Charter is established at the start of your project.
Benefits of a Project Definition
Using the Project Definition enables the project manager to identify the project requirements from a broader perspective, instead of focusing solely on deliverables. This ensures a clarity of scope before detailed planning begins.
What Is a Team?
A team is a group of individuals working toward a common
goal. Your team will include people from your organization, suppliers,
clients, and the project sponsor, each of whom bring their own skills to the
team.
As the project manager, you must ensure that the team members recognize the
skills of the other team members and the ways in which team members depend on
each other.
When a group of individuals truly becomes a team, they are committed to the team's values and objectives. They learn to work well together, they enjoy working together, and most importantly they produce the high-quality results that are key to a successful project.
Organization Types
The type of organization you work in affects the project managers ability to deliver a project successfully. The project manager must understand the challenges involved in managing a project within various organizational structures and must anticipate that over the life of a project the organizational structure might change. There are three types of organizational structures: functional, projectized, and matrix. These are described on the following page.
The matrix organizational
structure is the one that occurs most often in IBM. Because the emphasis
of this structure is project-based, it must be understood by IBM project
managers.
Matrix organizations evolved from the traditional management structure.
Its multi-disciplinary team members are drawn from various line or functional
units in a hierarchical organization.
Less anxiety exists about project termination because the project has been temporarily
superimposed on the functional organization. At project completion, the
functional organization remains intact.
Challenges
Matrix organizations are complex, and present certain challenges to the project manager. These challenges include the:
Matrix organizational structures affect the authority and responsibility of both the project manager and functional manager, the degree of communication within the project, and the communication flow.
Managing the Matrix
'.matrix
management is a charming form of management, full of variety and
disorder.'
From Project Management: A Managerial Approach by Jack Meredith
and Samuel J. Mantel, Jr.
For you, the project manager, successful operation within the matrix structure depends on the attitudes, actions, and activities of the people involved. Having the following elements in the project can help ensure a more successful project:
Tips for Making the Matrix Organization Work
The following list describes a few of the project management techniques that will help you, the project manager, in a matrix organization.
How Organizational Structure Influences Projects
You have been introduced to three types of organizational structures and how authority and responsibilities generally flow through each. The organizational structure has a significant impact on the project.
It is important to remember that the organizational structure often changes during the life of the project. The key issue is that the project manager needs sufficient authority to successfully execute the project. You cannot make the project commitments if you do not have the authority to make it happen. In all of your organizational planning ensure that you have all the authority you need, whether it comes from the organizational structure in the projectized organization or from the functional managers in the functional organization.
The following table illustrates how the levels of authority and responsibility differ between organizational structures. Note that in this table, moving from left to right, the authority of the project manager increases, as does the percentage of time dedicated to project management functions. In a weak matrix organization, the functional managers have more responsibility. In a strong matrix organization, the project manager has more responsibility. The functional managers are the providers of resources for the project and the project manager is the customer of the resource.
|
Project Characteristics |
Functional Organization |
Matrix Organization |
Projectized Organization |
||
|
Weak |
Balanced |
Strong |
|||
|
Project Manager's authority |
Little or none |
Limited |
Low to moderate |
Moderate to high |
High to almost total |
|
Percent of performing organization's personnel assigned full-time to project work |
Virtually none | ||||
|
Project Manager's role |
Part-time |
Part-time |
Full-time |
Full-time |
Full-time |
|
Common titles for project manager's role |
Project coordinator |
Project coordinator |
Project manager |
Project manager |
Project manager |
|
Project management administrative staff |
Part-time |
Part-time |
Part-time |
Full-time |
Full-time |
Organize the Project Team
Every team needs to agree on the team goals and how the team will work together to achieve those goals. One way to do this is to document the team guidelines and project ground rules. In WWPMM, these guidelines and ground rules are recorded in a document called the team charter.
The exercise of developing the team charter moves the team through the forming stage of group development into the storming, norming, and performing stages. Team members who join the team after the charter has been written must also understand and support it.
Team Charter
As the project manager, you must ensure that your team members are working together on the items that are important to you. The team charter helps you to do that by documenting the broad performance objectives, roles, responsibilities, and ground rules for the team, and the expectations for the project.
The team charter is divided into several sections:
Team performance objectives
The team objectives and the expectations for the project are documented in this section.
Building a successful project team requires you to take the following steps.
1. Select the right team members.
First, you must identify the specific project skills that are needed, and then bring in people with those skills. As the project continues, you must continue to validate the team's skills and resources to ensure that no critical skill areas are missing or misrepresented.
2. Organize the team.
As team members begin to work together, the team establishes a set of values. You, the project manager, must help team members commit to the team and its values. Each team meeting is an opportunity for team building and team development.
Another part of organizing a team is preparing an organizational breakdown structure (OBS). This WWPMM work product, which is presented in Module 3, defines the relationships between projects and subprojects, the reporting relationships, and the team structure of the project organization. All team members should have a copy of this chart, which clearly identifies their roles and responsibilities.
In order to support the team's goals, team members need to understand the background information about the project and team's mission.
3. Ensure open communication.
Communication should be easy and frequent, and team members must feel that they are part of the group. A variety of communication methods can be used to share information, including meetings, informal discussions, e-mail, and bulletin boards. All of these should be documented in the communication management plan.
4. Maintain the Team
After the team is formed,
your time, effort, and attention are required to maintain it. In addition
to making necessary adjustments in team personnel, organization, and
communication, you must consistently:
5. Motivate the team.
Once the team is
assembled, the team members must be motivated to work. The team
members' degree of motivation determines how much they give to the project and
how supportive they are of the project goals. As a project manager, you
might not have the same leverage as a functional manager, who controls
motivators such as pay and promotion. As a result, you must choose your
motivators carefully.
All motivators can be classified as appealing to either logic or emotion.
Logical motivators can be positive, for example, benefits or quality; negative,
for example, loss of benefits and poor quality; or educational, for example,
objectives, conditions, explanations, demonstrations, and good judgment.
Emotional motivators include generating trust and confidence, stimulating
thought, and avoiding hidden agendas.
6. Recognize and reward team behavior.
You must recognize and reward team behavior and support team-based
incentives. In doing this, you should emphasize the team's collective
performance rather than singling out individuals for their specific
achievements.
7. Respond to team change.
Throughout the life of a project, individuals will be added to the team and
members will leave the team. Fluctuating team membership is a challenge
for every project manager and must be recognized and dealt with in a direct and
timely way.
Considerations for the Multicultural Team
When managing a multicultural team, always consider variations in social customs, time zones, protocol practices, and language proficiency. Failure to recognize differences often leads to hurt feelings and misunderstandings that might affect the smooth functioning of the team. Some rules are:
What Is Communication Management?
Many new project managers do not realize the importance of communication to project success. The Project Management Institute (PMI) says that project managers spend about 90% of their time communicating. That means you need to have a plan so that communication on your project is timely, is directed to the right audience, and get the message across. But remember, the project manager does not have to do all the communicating. Team leaders and project staff can support the communication. Lets examine the process for developing a communications management plan.
A good project team must have effective communication within the team and between the team and the project stakeholders. A hazard in project management is the belief that communication links are functioning effectively as long as people are communicating with one another. The truth is that communication must be well planned to be effective. As the project manager, you are responsible for planning, building, and maintaining effective communication.
To do this, you must first recognize the variety of communication that a project needs. Different communication channels have different requirements. For example, communication from the project manager to the project sponsor and the client has one set of requirements. These differ greatly from the requirements of communication between project managers and their teams and subprojects, or between the overall project manager and the project managers of subprojects or related projects.
Suppose you want to convince a key stakeholder of the merits of the solution you are building. What medium do you think will be most effective? Will sending an e-mail be enough to convince her? Probably not. E-mail and other written forms are best used to transmit information. To gain commitment from a stakeholder, you usually need to personally connect with him or her one to one or in a group meeting, and secondarily over the telephone.
The medium for each communication link must also be defined. Some communication takes place in weekly status meetings, including face-to-face meetings, electronic meetings, and conference calls. Alternatively, communication could occur as written reports, electronic memos, or e-mailed documents. Internet or intranet posting is another potential communication medium. Project information can be updated and posted online where people who need it can access it at all times.
Your decisions regarding communication will be affected by the
geographic location of the team members, the frequency of communication
required, and the technology that is available.
If all the team members are in the same location, you might want to consider a
team room approach.
Developing a Communication Management Plan
The various communication requirements and your decisions about them are
documented in the communication management plan. The plan includes what
is being communicated, how it is communicated, who is communicating, to whom is
it being communicated, and how often this must happen. You should create
the plan during the project planning activities. As you start execution,
it might be necessary to expand the plan or adjust it.
There is a WWPMM work product description and a template to assist you in creating a communications management plan. These, like all WWPMM work product descriptions and templates, can be found at the WWPMM Web site.
Determining Project Communication Requirements
The purpose of communication planning is to be proactive, anticipating what type of information stakeholders will need and when they will need it. If you are not proactive, you will end up spending lots of time responding to ad-hoc information requests, or worse, lose commitment from key stakeholders.
Before you can create a communication management plan, you need to determine the project's communication requirements. To do this, you must first review:
Next, the information needs of the various stakeholders should be carefully analyzed to determine the information that will be provided and the sources of that information. Include the requirements of the project team, the sponsor, the suppliers, the delivery and performing organizations' management, and others who might need information regarding the project. Information for this analysis can be gathered by :
Once that is done, you must document the information requirements of each stakeholder group. Be aware that policies of the delivery organization often define the format and procedures for status meetings and project reporting.
Creating a Meeting Matrix
Creating a meeting matrix can make it easier to understand the communications that are required for the project. The matrix should outline the purpose, content, and frequency of all periodic meetings.
|
Meeting |
Purpose |
Frequency |
Media |
Author or Owner |
Attendees |
|
Team Leads |
Deliverable Status and Action Item Reporting |
Ad hoc |
Sametime |
Ron Brown |
Project Team Leaders |
|
Team Announcement |
Review Status and Actions on the Request for Announcements |
Weekly |
Face to Face |
Ron Brown |
RFA owners |
|
E-Announcement |
PDT for a major e-announcement and delivery |
Monthly |
Conference Call |
Rosemary Lopez |
Product Owners, RFA Owners, Finance, Manufacturing, Engineering |
|
Interlock |
Announce and Ship Readiness with all IBM Divisions and Corporate Staff |
Quarterly or Weekly at Announcement |
Conference Call |
Vijay Kadayam |
Corporate and Division Representatives |
Developing the Communication Management Plan
Document the scheduled meetings, reports, and other communications in a communication management plan using the meeting matrix as one of the inputs to the plan.
A WWPMM work product description and a template are available to assist you in creating the communication management plan work product. For information about this and for descriptions and templates for all WWPMM work products, go to the WWPMM Web site.
Introduction to the Seven
Keys To SuccessTM
This module discusses the Seven Keys To SuccessTM and how this
framework is being used within IBM. It is being deployed throughout IBM
and is key to the success of IBM's projects. Throughout this course, you
will find material that answers the following questions:
Project Success Depends on Executive Commitment
Project success is
directly tied to effective involvement of business executives and to the speed
at which decisions and actions are made. According to the Gartner Group,
the Project Management Institute, and other observers of project management
performance, the number one reason why projects fail is related to executive
commitment and leadership.
Gaining executive commitment and leadership requires communication both to and
from executives.
The Seven Keys To SuccessTM is a means to ensure successful
projects. It is a framework for assessing and communicating project
health. This framework can be used as an effective communication vehicle
with executives and other stakeholders on projects.
The Seven Keys To SuccessTM is complementary to the other project management methods, tools and techniques used in IBM.
The Seven Keys to SuccessTM system was created by and for project managers to provide PMs with a systematic approach for dealing with their unique personal challenges in managing projects.
The original research and design team knew there were many methods and tools for planning and controlling projects and the various disciplines, but none solely addressed the PMs unique situation and mindset. The team created a consistent and cohesive approach applicable for all types and sizes of projects regardless of the project phase or circumstance. The resulting Seven Keys to SuccessTM is a simple but highly effective system for all PMs to use in pursuing project management excellence and emulating world class project management.
Many studies validate that appropriate engagement of appropriate stakeholders is the primary driver of project success. The Seven Keys to Success provides an excellent but simple means for engaging and communicating with not only all key project players but also the executives who must understand the health of the project and take appropriate actions to ensure success.
Some of the highest performing and most successful Project Managers and Team Leaders are invariably doing the essence of the Seven Keys to Success. This IBM PM approach simply provides a convenient framework and language for leveraging these best practices across all players. The Seven Keys to Success is included as part of WWPMM and is complementary to the other tools and methodologies used in IBM.
How are the Seven Keys to Success used?
Whats the Story Behind the Seven Keys to SuccessTM?
The Seven Keys to SuccessTM system was created by and for project managers to provide PMs with a systematic approach for dealing with their unique personal challenges in managing projects.
The original research and design team knew there were many methods and tools for planning and controlling projects and the various disciplines, but none solely addressed the PMs unique situation and mindset. The team created a consistent and cohesive approach applicable for all types and sizes of projects regardless of the project phase or circumstance. The resulting Seven Keys to SuccessTM is a simple but highly effective system for all PMs to use in pursuing project management excellence and emulating world class project management.
Many studies validate that appropriate engagement of appropriate stakeholders is the primary driver of project success. The Seven Keys to Success provides an excellent but simple means for engaging and communicating with not only all key project players but also the executives who must understand the health of the project and take appropriate actions to ensure success.
Some of the highest performing and most successful Project Managers and Team Leaders are invariably doing the essence of the Seven Keys to Success. This IBM PM approach simply provides a convenient framework and language for leveraging these best practices across all players. The Seven Keys to Success is included as part of WWPMM and is complementary to the other tools and methodologies used in IBM.
How are the Seven Keys to Success used?
What Is the Meaning of the Three Colors?
The Seven Keys To Success are used to assess the health of projects. Based on criteria agreed upon by the project sponsor and project manager for a project, the status indicator of each key reflects one of the following three colors:
Traditional project management status indicators tend to indicate the severity of the problem but the Seven Keys indicate both the severity of the problem and how quickly corrective action is needed.
No project team will have
all the keys green all the time.
The status indicators focus the project sponsor and project team members on the
issues most critical to the success of the project.
Defining the Technical Environment
The last few sections dealt with managing the people on the project. Now lets examine managing the environment in which the work is conducted in. Have you ever worked on a project where the work conditions were poor? Did this affect the project team? You know from your own experience that adverse working conditions can affect team morale and efficiency and the quality of the project deliverables. As you might have guessed, it is the project managers responsibility to ensure the working environment will promote teamwork and the successful completion of the project.
The technical environment is the collection of physical space, hardware, software, netware, and equipment that is shared by the project team and used to support a project or a subproject. The technical environment includes the following items:
An office software suite, including word processing, spreadsheet, presentation, and drawing tools
Office communications, including e-mail and access to shared files
Project management tools
Tools that support technical activities in all project phases
Surveying the Technical Environment
The technical environment might or might not be in place before the project starts or additional tools might be needed. Project needs, costs, expected benefits, and risks must be analyzed before deciding whether to build a technical environment or adapt one that already exists.
On some projects, part or all of the technical environment is provided by the sponsor. On other projects, the technical environment is a deliverable, to be left behind or transferred to the sponsor at the end of the project. In any case, in planning the project, the requirements for the technical environment must be defined.
Managing the Technical Environment
Managing the technical environment includes understanding, planning, acquiring, installing, and removing the technical environment. It is important to have a plan that provides a clear description of what must be done.
Activities for managing the technical environment include performing a needs analysis, developing an architecture, planning for implementation and maintenance of the environment, and planning for the eventual de-install of the environment.
As part of your technical environment, you should have project management tools that provide:
Project management and operational scheduling
Time tracking
Cost tracking
Risk management
A project control book (PCB)
Access to business systme
Team is High Performing Key
The project manager has
the responsibility of ensuring that the project team is high performing.
This means that the team has high morale, and is getting the job done. It
is important to remember that the project team might include client staff in
addition to IBM staff. It can be easy to tell whether a team is high
performing: team members have open communication, they share expertise and
issues, and the staff volunteers to take on new tasks.
Here are some criteria for assessing the Team is High Performing key.
Healthy Signs
Morale is good.
The team is diverse.
Unhealthy Signs
Tension can be felt.
Turnover is high.
Working conditions are poor.
This indicator, often overlooked, is about talent and experience. It is also about morale, trust, physical environment, reward, and recognition.
What happens if a team is not high performing?
Have you ever worked on a project and the team was not high performing?
Was their frequent miscommunication between team members, a lack of information
sharing, and distrust?
And how did this impact the project?
More than likely, it impacted the Work & Schedule are Predictable
key. When a team is not working at its best, deadlines are missed, and
the quality of the work is not up to an acceptable standard. The Delivery
Organization Benefits are Being Realized key is also affected because of the
additional time and cost incurred to make up for the teams poor performance.
As the project manager, it is your responsibility to proactively ensure the team is high performing. So make it a point to review the teams overall performance and plan actions to improve the team environment, moral and productivity.
The following are the WWPMM domains, work patterns, work products, and templates associated with the topics in this module. For information on all of these resources, see the WWPMM Web site.
WWPMM Domains
WWPMM Work Patterns
WWPMM Work Products
WWPMM Templates
The Importance of Planning
Think back. Have you ever worked on a project in which the team was not well organized? What happened to the project?
Effective teams don't just happen because the project manager was
lucky or had highly-placed friends. I have seen great project managers
with great teams fail because they didn't spend the time defining and
documenting how their team would work together. I have also seen other
cases where a team with mediocre skills was able to miraculously fulfill their
commitments because of the up-front planning that was done and because the team
worked well together and communicated with each other.
'I have a team charter. Why have a communication
management plan too?'
I believe a communication management plan is key to a
successful project for the following reasons.
The plan facilitates efficient communications and quicker responses, because
everyone knows who is supposed to get the information, as well as how the information
is delivered and how often. We all have a story about the stakeholder who
surprises everyone and stops the project saying, 'I didn't know' or
'Nobody told me.' A stakeholder analysis ensures the PM
considers all stakeholders and their information needs. The communication
management plan is the plan that ensures that the stakeholders receive the
documentation and communication they need, and answers their questions.
Remember that project managers are not the only ones responsible for project outcome. Communication between the project manager, team, and stakeholders is crucial. I remember early in my career, I was a project manager on two very different projects. One was my best project, and the other was my worst project. These two projects occurred one right after another in the same year. One project had a Chief Information Officer who appeared to me to actively work to see the project fail. And he succeeded; it failed. The other project was the best project I had ever managed. In this project, it was the client who made the difference. This client took responsibility, made difficult decisions, took political heat, and truly owned the result. Could it be that I completely failed in one project and was a success in the other? Did I change tactics or become a different person? No, in fact my best project happened immediately prior to my worst project. This was my first lesson that we, as project managers, are not the only people responsible for project outcomes, whether the outcomes are good or bad. So its important to understand your stakeholders and have a plan for keeping them committed to the project.
Finally, one of the most frustrating things that I have experienced as a project manager is when team members are spending time talking to the clients or sponsors. First of all, they don't have time to do the work I need for them to do and talk to those people. Also, they only see a small part of the whole project. Often times, their opinions of the other parts of the project are not based on facts, and then I have to spend hours of my time doing damage control.
I have found that if I create a communication management plan and get the team to agree to it, it really does save me and my team time and money.
'Why is a team charter important?'
In my opinion, the real value of a team charter is the exercise that you go through to create it. It forces you, as the project manager, and your team to discuss how you're going to work together. It forces you to agree on the project goals and the roles and responsibilities of each of the team members. Unfortunately, if you don't create the team charter, most of the time you also don't go through the thought process to figure out how the team should function.
'Why do I need to have a technical environment plan?'
I think the technical environment plan is critical. We're all communicating and working using technology. Unfortunately, even within IBM, we're using different software programs and tools or we're on different levels of those programs. When we're not on the same levels or using the same programs, we have communication problems. The purpose of writing a technical environment plan is to find those areas where we're not on the same software and fix them before we get to a critical point in the project. This is really just common sense.
The place we really see problems is with our suppliers and customers. Many of them aren't running our standard products, and some of them don't want to be. In those cases, we need to decide early in the project how to best communicate with them.
Team advice
Let me give you a bit of advice about the Team is High Performing key. When I was managing the integration project for Coppets-Close Hotels in the UK, I learned first hand how powerful it can be to have a truly diverse team: diverse in style, in nationality, in gender, and in life experience. And I also learned how hard it can be to bring such a team together, how easy it is to convince oneself to take shortcuts in these efforts, and how tiresome it can be to continually display the leadership that binds the team together. Do not let these challenges discourage you. Fight for diversity on your teams, and fight for the time and resources you need to build trust and communications in your teams. I guarantee your project's performance will benefit.
The main idea of collecting requirements involves a staged process. Remember the following sequence:
After the requirements are collected, the project manager closes this loop by returning back to the original gathering requirements phase.
Communicate the business results by examining:
The Process for Defining Requirements
After the project charter
is created, you will probably spend time talking to the sponsor and other
stakeholders about
what they expect from the project. They will have many ideas about what
they need, some of which will conflict with one another. As the project
manager, your responsibility is to determine which of these needs the project
will actually fulfill the requirements. Requirements define what the
project will deliver. The requirements document is a formally documented
description of the sponsor's needs that must be addressed by the project.
Requirements state what the sponsor wants and what the project staff has agreed
to deliver.
Requirements also serve as the basis for developing project plans. Your
project team needs requirements in sufficient detail to begin work.
The process of defining requirements includes the following steps:
Needs
The information you gather about what the sponsor and stakeholders want translates into needs. Needs are activities, services, products, and deliverables that are useful, required, or desired. Your job is to turn needs into either requirements or exclusions. Exclusions are statements of what you will not provide; that is, 'not-included' requests. They are ideas or requirements for a future project, needs that you will not be meeting or providing in the current project.
Needs are initially identified when a proposal is developed. These needs are documented in the request for proposal, marketing letters, project charter, contract, and internal document of understanding. These needs are usually too general to be useful to your project team. An example of a general or high-level need is 'Train employees to operate a system that does XYZ on ABC's platform.' Sometimes, details are included; but, usually the details that you and your team require to make this project successful are missing.
Asking Questions
As the project manager, you have many questions to ask about general needs. Examples of these questions are:
These questions should solicit the detailed requirements that are meaningful to you and your team.
Always gather needs at the beginning of a project. Also, when you take over a project that has already started, you must gather needs again to ensure that the original needs are still valid. They might have changed.
Finding Needs
Needs are documented in several
places in project documents, including sections of the request for proposal
(RFP), the statement of work (SOW), and descriptions of deliverables and
evaluation criteria. Carefully review all the project documents to look
for obvious and hidden needs.
Another important source of needs is the project sponsor. The sponsor can
clarify what you have read in the project documentation. In some cases,
you might find that not many needs have been documented, so the sponsor must
provide them. The sponsor will also tell you who else you should talk to,
such as stakeholders or customers of the sponsor, to enable you to clarify the
needs of the project.
Procedures
To gather needs:
Interviewing the Sponsor
The sponsor will give you
his or her interpretation of the needs. The sponsor might also give you
the names of other people to interview. You can interview the sponsor and
other people, or you can use requirements-gathering tools, such as
brainstorming, the nominal group technique, focus groups, workshops, and
affinity diagrams.
Use structured, unstructured, or semi-structured interviews to identify
needs. The interview process involves identifying each participant, and
asking a series of questions based on that person's role in the project.
First, you might need to explain to the sponsor and project staff what you are doing, such as gathering needs, categorizing them, and establishing the requirements baseline. You might also need to explain how that baseline is the basis for the project plans that you will develop.
Interviewing the Sponsor
In your interviews, always cover the following basic questions: when, where, why, what, and how. The following are some sample questions:
The next step in the requirements-gathering process is to categorize needs into either requirements or exclusions.
Transform Needs into Requirements and Exclusions
Examine each identified need and determine whether it should be included in your project. To make this decision, ask these questions:
As you think about the needs, remember what the sponsors told you. In the end, the sponsor must agree with your plans, so involving the sponsor early in the requirements-gathering process will save you time and headaches later.
Each need that is not a requirement is an exclusion. Document the exclusions so that the sponsor and other stakeholders know what you and your team will not provide in the project.
Deciding: Requirement or Exclusion
After you have gathered needs, categorize them as either requirements or exclusions. In effect, you are deciding to:
Documenting Requirements
Documented requirements must be clear and concise, because
they form the basis of your project plans. As you write requirements,
determine whether they can be misinterpreted. Writing requirements that
can't be misinterpreted is a difficult task. To help ensure that
requirements are clear, include graphics, models, and other visual
representations, where appropriate.
After you have written the requirements document, ask your team to review it to
be sure they have the detail they need to get started.
Always validate documented
requirements with the project sponsor, stakeholders, and project team.
Validation reviews help you understand whether what is written really describes
what each person needs. The key to the requirements process is validation
of the requirements by all parties. Validation lets you know that
everyone agrees with the requirements and that you can proceed with the
project. You use validated requirements to establish the .
The requirements baseline is the requirements document that has been approved by the sponsor, stakeholders, and key members of the project team. The baseline defines what the sponsor wants and what the project team has agreed to deliver. It will not be changed unless the sponsor, stakeholders, and you, the project manager, approve of the change.
Everyone on the team must understand that the requirements for
the project are defined in the baseline and that any proposed changes must be
submitted to you in writing. Changes to the baseline document could
affect the cost and schedule of the project. To learn more about the
change control process and how you use it to change the requirements baseline,
refer to Module 9, 'Understanding Change Management.'
Establishing a requirements baseline is one of the ways you control the scope
of a project and avoid scope creep. Scope creep occurs when project
requirements keep changing. When scope creep is out of
control, you never finish a project; the schedule keeps moving out and the
costs keep increasing. As a project manager, enforcing the requirements
baseline is one of your most important tasks.
If you do not validate the requirements now, its likely that sometime during the project a stakeholder will come back and say 'I didnt agree to that' and throw the project off-course.
To validate the requirements you have gathered and documented, distribute your findings to the sponsor, stakeholders, and members of the project team to review. As with any review cycle, be sure to tell reviewers when you want their comments returned.
After you receive all comments:
This approved document is the requirements baseline.
Stakeholders are Committed Key
The word 'stakeholder' has many definitions and connotations. You can think of a stakeholder as anyone who is impacted by the project, or who can impact the project. As the project manager, you need to actively manage stakeholders throughout the project lifecycle to ensure their ongoing commitment to the projects success.
Criteria for assessing the Stakeholders are Committed key are:
How do you know whether the Stakeholders key is healthy or unhealthy? Look for these signs.
Healthy Signs
Executive incentives are tied to project results.
The client makes investments in change management and training.
Subject matter experts are dedicated full-time.
Unhealthy Signs
No executive sponsor is visible.
Key stakeholders miss meetings.
People are sabotaging efforts.
Resistance to new ideas is evident.
No experts are available.
Business Benefits are Being Realized Key
This key is closely
related to the Stakeholder key. Clients want solutions to their business
problems not just a strategy or system. The project team and the customer
must understand why the project is being undertaken, and they both need to
understand how the project benefits the customer. If stakeholders do not
perceive any business benefit, they will probably lose commitment to the
project.
Here are some criteria for assessing the Business Benefits are Being Realized
key:
And here are the healthy and unhealthy signs to look for.
Healthy Signs
o A compelling reason to implement is evident.
o The difference to the business can be measured
Unhealthy Signs
o Members of the team keep asking, 'Why are we doing this?'
o People are sabotaging efforts.
o Time is not important.
o Cost is too important.
Some projects start out without a sound business case. Such projects are doomed to failure. Some projects have sound business cases but, somewhere into the project, they lose that focus and never regain it. Ensure that your stakeholders stay focused on the business benefits; otherwise they will focus on how much the project costs.
I cannot overstress the importance of understanding all of the
customer's requirements for a
project. A thorough understanding of all requirements is critical to
project success.
I've also learned how important the requirements baseline is to delivering a project on time and on budget. At the beginning of a project, everyone has to agree on what is being delivered. Everyone has to understand that future changes must be agreed to by the sponsor, stakeholders, and you before the changes are made.
To create the requirements baseline, the stakeholders and
project team need to understand the business benefits of the project.
I've seen the requirements definition process go awry in many ways. Some problems are so subtle that they do not become apparent until the project is almost finished. The primary source of cost and schedule overruns is problems relating to requirements. These problems can lead a customer to reject a deliverable or a major rework of the project. Poorly defined requirements can also lead to project failure.
Some of the common problems I've encountered or heard about include:
To help avoid these pitfalls, work closely with the sponsor, avoid shortcuts in the requirements-gathering process, clearly identify the sponsor, and try to avoid imposing your biases, or those of anyone else, on the sponsor's needs.
The requirements-gathering process is iterative. It is important to redo the process and ask a lot of questions.
After you have identified the project requirements for your project or subproject, the next step is to determine how you are going to deliver those requirements.
To do this, remember to define the project deliverables, develop a WBS baseline, and describe the criteria for determining if the scope is realistic and managed. Also remember that although the product breakdown structure (PBS), work breakdown structure (WBS), and organizational breakdown structure (OBS) are all different, they complement one another; they are different ways of viewing and decomposing the project.
What does it mean to decompose a project?
Decomposition is the subdividing of the major project deliverables into smaller, more manageable components. You identify the top-level elements of the project and then divide the elements into manageable pieces for scheduling and tracking.
What Is Decomposition?
Decomposition is the subdividing of the major project
deliverables into smaller, more manageable components.
The purpose of decomposition is to identify the top-level elements of the
project and then divide the elements into manageable pieces for scheduling and
tracking. This process is used to develop the PBS and the WBS.
The OBS shows the project organizational unit responsible for
each of the deliverables and components.
Types of Breakdown Structures
There are three types of breakdown structures. Move your mouse pointer over the name of each breakdown structure to
What Is the PBS?
The PBS is a hierarchical decomposition of work products into components. The PBS focuses on what must be produced and is required to create the WBS, which focuses on how to produce the work product. Each level of the PBS represents an increasingly detailed view of the components.
There is a Worldwide Project Management Method (WWPMM) work product description and a template that assists you with the creation of the PBS work product. You can find this information and descriptions and templates for all WWPMM work products at the following Web address:
Worldwide Project Management Method
What Are the Benefits of the PBS?
The PBS helps you to:
Creating the PBS
Create the PBS using the
following steps.
Gather the data as follows:
A WWPMM work pattern (Build Project Organizational Unit Work Plans) and two WWPMM work products (the Deliverable Definition and the Work Product List) contain descriptions and templates to assist you with the PBS content. These can be found, along with descriptions and templates for all WWPMM work products, at:
Worldwide Project Management Method
Create the PBS using the data that you gathered as follows:
Review the PBS with others to obtain their agreement, and then complete the following tasks:
What Is the WBS?
The WBS is a hierarchical decomposition of all the activities the project team must complete. The WBS defines the total scope of the project and provides the basis upon which work can be scheduled.
Each level of the decomposition increases the detailed view of the tasks to be completed to create work products. Verbs are used to describe each activity. The hierarchy has as many levels as required to define the work. The number of levels usually varies from one major element to another. The WBS focuses on how to produce the work products that are defined in the PBS, which focuses on what to produce.
This figure illustrates two ways to show the same WBS decomposition. One is a tree diagram, and the other is an indented list or outline.
When Is the WBS Created?
The WBS is generated after the team understands the work products to be developed. Development begins when deliverables are identified and agreed to by the sponsor. From this point in project planning, the project scope can be described in measurable and discrete work efforts.
The Levels of the WBS
The WBS has as many levels as are required to define the
activities to the level of detail needed to successfully plan, monitor, and
manage the work effort.
An activity is an element of work at a particular level. Each activity
results in a work product that is distinct and has verifiable completion
criteria. Work products that are given to the sponsor are called
deliverables (for example, a software program with the functionality requested).
Not all work products are given to the customer (for example, those that are
necessary to manage and control the project, such as software that generates
monthly project status reports, are not given to the customer but do require
work effort to develop). The elements of the WBS often have common work
activities for similar projects. These common elements are called work
patterns.
The lowest level of the WBS is the work package. A work package is a group of work items assigned to a single person or small group to be done over a short period of time. An example is a software application that is being developed in-house while the hardware is being developed by an external supplier. The WBS for the software might be decomposed into two-week activities, which results in work packages at the sixth, eighth, and tenth levels of the WBS. Alternatively, the hardware might be decomposed to the subcontract level of 50 weeks of activity at the third level in the WBS. The subcontractor needs to decompose the hardware work into smaller activities to enable effective planning and scheduling.
When creating the WBS, the project manager must examine each level of the structure to ensure that the project is effectively planned, executed, controlled, and closed. Each level must be examined for dependencies among components, acceptance criteria, risks, ownership, milestone schedule, progress reporting, and relationship to the solution architecture. As a project manager, you must consider each of these aspects. You must also look at alternative decompositions to reduce dependencies, tie acceptance criteria more closely to the contract, avoid or reduce risks, permit measurable milestones, allow clear progress reporting, and maintain a relationship to the target solution.
The Levels of the WBS
The following examples depict two-, three-, and four-level WBSs. These are partial examples because only one item at each level has been expanded to the next level. A complete WBS expands to the level needed to define and manage each item. Normally, different items are expanded to different levels.
Click each button to read the examples:
The second level is a decomposition from the first level. The entire project test plan includes the unit test, a system test, and an acceptance test.
The third level is a decomposition of the system test second-level element. For a complete third level, all elements from the second level must be expanded. To execute the system test, you must write test cases, prepare the test environment, conduct the test, and analyze the results.
The fourth level is a decomposition of the third-level element, which is to write test cases. For a complete fourth level, all elements from the third level must be expanded. Obviously the WBS example becomes unwieldy for a normal project. For this reason, the WBS can also be depicted as an indented list.
The WBS Dictionary
The WBS dictionary
is a repository for descriptions of work elements and other key information
such as budgets, basis of estimate, and staffing. The dictionary contains
detailed background information about each work element. It might also
include acceptance and completion criteria. Using the dictionary,
team members can capture information about each activity.
After an activity is defined, that definition remains throughout the
project. The definition is used to explain activities to employees and to
clarify where work begins and ends on an activity.
The dictionary helps
determine whether the project manager has identified the skills needed to do
the work.
It should contain the following information for each element:
What Is the OBS?
Now that you have decomposed the product (PBS)
and the activities (WBS), it is time to think about how the people working on
the project will be organized. The OBS shows how the project is organized
by displaying the names of staffing resources for a project. It indicates
who is responsible for the activities in the WBS. The OBS describes the:
Relationships between the subprojects and the project organizational units
Reporting relationships between the project organizational units
Team structure of the project organizational units
Reporting relationships between the delivery and performing organizations, including the subcontractors
The OBS contains the subproject definitions, the project organizational chart, and the team structure.
The Importance of the OBS
Have you ever worked on a project that did not have an Organizational Breakdown Structure? What happened? More than likely, project staff did not know who else was working on the different parts of the project, and did not know who to ask when questions arose. The OBS helps project staff understand how they fit into the overall project and how information flows between the units delivering the project.
Creating the OBS
To create the OBS, complete the following steps:
Example of a PBS
In the following example, there are four deliverables: cooked pasta, canned sauce, dinner salad, and garlic bread. Shown following the deliverables are the work products that are needed to create the deliverables. For example:
How to Get Started Creating the WBS (continued)
The questions to ask yourself as you start to create a WBS are:
Creating the WBS
Follow these guidelines to
create the WBS:
Gather all the data as follows:
Create the WBS by using the gathered data and following these guidelines:
Review the WBS with others to get their agreement as follows:
Questions to Consider
Ask the following questions as you are developing or reviewing the WBS:
Example of an OBS
The OBS shows how the project is organized by displaying the
names of staffing resources for a project. It indicates who is
responsible for the activities in the WBS.
The OBS contains the subproject definitions, the project organizational chart,
and the team structure.
The diagram shows an example of an OBS structure.
Scope is Realistic and Managed Key
It is unusual for a project to finish without at least one change request to the scope from either the project sponsor or the project team. Therefore, the team must expect scope changes and manage them effectively.
However, if there are many change requests right after the start of the project, the scope has not been not well defined. Make sure that the team spends enough time in the planning phase to have a detailed understanding of the project scope.
Here are some criteria for assessing the Scope Is Realistic and Managed key.
As the project manager, look for these signs.
Healthy Signs
Unhealthy Signs
Scope is Realistic and Managed Key (continued)
As you saw in the previous modules, the stakeholder and
business benefits keys are closely related.
To which other key do you think the Scope key is related?
Benefits of the PBS, WBS, and OBS
Think about projects you have worked on that did a good job
creating the PBS, WBS and OBS.
How did these structures help the project manager execute and control the
project?
I believe that creating the WBS and the PBS are the most important
things I do as a project
manager. When I create the PBS, I identify all the deliverables and work
products (what) first.
After I understand the work products, I can start to create the WBS.
The WBS helps me to identify all the (how) activities,
including dependencies and hidden issues.
As I go through the process, I define the completion criteria for each
activity. When I am done, I have a great road map that I can use to help
me finish planning the project. I find that I use the WBS through the
entire project as a reference point to ensure that I haven't forgotten
anything.
The OBS is critical for helping me to plan my resources. By creating an OBS, I have a picture of the entire project organization, which I find very helpful.
Example of Uses of WBS, PBS, and OBS
I really like the following chart, which depicts the uses of the WBS, PBS, and OBS.
At the upper left of this chart, you can see the requirements for the project as inputs to the WBS, OBS, and PBS. The requirements are the Supplier Management Plan, the Integration Strategy, and the system solution.
The project management outputs from the WBS, PBS, and OBS are the Status Reporting, the Cost Estimation Development, and the Project Schedule at the bottom of the chart. At the upper right is the two-way Communications Management that occurs during the entire project.
Risk management is proactive decision making. The Risk Management process provides for an iterative means to plan, track, and react to risk. As a part of this process, you create a risk management plan to identify risks you might encounter on your project. When creating a risk management plan:
The Risk mitigation is what you do to ensure that the risk event does not happen. Risk response is what you do when it does happen. So the risk management plan is the whole response process.
What Is Risk Management?
Risk management provides an environment for proactive decision making. As a framework for the iterative process of planning, tracking, and reacting to risk, the risk management process includes:
To address changing
conditions and project priorities, you must analyze risks throughout the life
of the project, beginning in the project selection phase. As new risks
are identified, you must develop strategies and plans to address them.
Risk Management Steps
The chart on the following page shows the steps that you follow when performing risk management. Remember, risk management is an iterative process. You must go through this entire process regularly to ensure that any new risks are identified and addressed.
Note: Step 4 (risk tracking and control) and step 5 (risk reaction) are covered in Module 10, 'Project Control and Execution.'
Step 1: Risk Identification
In Step 1, search for and identify the risks. Determine
risks that could be a potential loss or lead to negative consequences for the
project. Also, look for risks that represent opportunities that might be
exploited.
Step 2: Risk Analysis
In this step, define the probability and impact of each risk to determine the
exposure. You can then prioritize the risks to determine how the project
team is going to address each one.
Step 3: Risk Response Planning
In this step, you decide what, if anything, should be done with the risk. To help you decide, consider the responses to the following questions: Who owns the risk? What should be the response to the risk? What actions and plans should be put in place to address the risk?
Step 4: Risk Tracking and Control
In Step 4, you continually collect and analyze data about the identified
risks to determine whether action must be taken.
Step 5: Risk Reaction
In this final step, implement the identified action plan in response to actual risk occurrence. You also close the risk, if appropriate.
Your Role in the Risk Management Process
You, as project manager, are responsible for managing risk. Your role includes the following:
Considering the Objectives of Stakeholders in Risk Management
Because perceptions of risk might be affected by a stakeholder's objectives, try to involve all stakeholders in the risk management process early in the project life cycle.
Involving as many stakeholders as possible in the risk management process helps to ensure that the greatest number of potential risk factors and risk events are found and that resulting strategies more closely meet stakeholder objectives.
Identifying Risks
When you identify risks, your goal is to list all of the significant potential risk events that could affect the outcome of the project.
Components of risk
For managing risk, there is one more component to consider:
A risk factor is a situational factor that has been identified as leading to a risk. Risk factors should be identified early and projects should be reviewed regularly to ensure that no significant risk events are overlooked. Repeat the risk identification process on a regular basis, as part of your key checkpoints or key milestones. When developing the list of risks, be thorough, but realistic.
To begin, first look for risk factors such as poor estimates, requirement changes, or design errors. You can then determine possible events from these factors.
When you identify the timing when a risk event can occur consider whether it is a one-time risk or if the risk can occur more than once. Most risks identified early in a project are one-time risks, but consider a risk of not being able to complete a step in the project because a client does not provide you with data that they are obligated to provide monthly. Every month there is a chance of missing a delivery to your project so that the frequency of this risk is monthly.
Using Inputs to Identify Risk Events
A variety of inputs should be used to help identify risk factors and risk events. For example, when using the WBS, look at each work product and consider what can go wrong. In this instance, the WBS is the input. Examples of other inputs include:
As you progress on the project, some other areas to look at are:
Questions That Help Identify Risks
Following is a list of questions related to key project areas that might help you to identify risks:
Techniques for Identifying Risks
Some of the many techniques and tools to identify risks using input from other people include:
The Purpose of Risk Analysis
The purpose of risk
analysis is to gather data about risk events. You can then use this data
to decide which risk events to mitigate.
Risk analysis is a continual process conducted throughout the life of the
project. As the project progresses, the analysis for a risk event might
change due to changes in the environment.
Risk analysis includes:
Defining Probability and Impact
To evaluate a risk event,
you examine the probability of the risk occurring and the impact it will cause
if it does occur. You can use either a qualitative or quantitative
approach to estimating.
Qualitative Analysis
Estimating Probability
Using a Qualitative Analysis
Using a qualitative analysis to estimate probability, you assign a low,
medium, or high category to the probability that the event will occur as
follows:
Because low, medium, and high are relative terms, ensure that everyone on your team involved in the process of estimating probability uses these terms similarly.
To illustrate, consider an example of a person skydiving. When a person is skydiving, a parachute malfunction is a risk with a low probability.
Defining the Impact Using a Qualitative Analysis
After you define the probability for each risk event, you define the impact. To do so, ask yourself, what the impact to the project will be if this risk occurs. In a qualitative analysis, impact can be categorized as low, medium, or high, as follows:
The following graphic shows the relationship between impact and probability. The vertical axis represents impact, and the horizontal axis represents probability. Each 'X' represents a specific risk, by placing the 'X' in the diagram you can see their impact, probability and global qualitative value.
Estimating Probability Using a Quantitative Analysis
Another approach to estimating probability and impact is a quantitative
analysis. A quantitative method uses a numeric scale, usually from 0 to
1, to measure the probability of an event occurring, where 0 means an event
would not occur and 1 means it will occur. The impact is
measured in the same way, where 0 means no impact and 1 means the maximum
impact possible.
Using the parachute example, the risk of an FAA licensed dual-parachute (a
back-up chute is required) failure as determined from US FAA data collected in 2005
is .000016 (35 incidents from over 2,000,000 jumps), but since death is the
result, the impact of a dual-parachutes failure is 1.0.
Assessing Risk Exposure
Risk exposure is a combination of the probability and the impact of the risk. The project manager is responsible for determining the risk exposure, using probability and impact estimates and the following matrix tool. Risk exposure has more than one dimension, such as cost, schedule, quality, and customer satisfaction, that should be considered.
In this matrix, the risk decreases as you move from right to left, or top to bottom. To illustrate, in the parachute example, low probability and high impact results in a medium risk exposure.
Prioritizing Risks
Prioritizing risks
involves deciding whether risk events are worthy of attention. Placing
one risk next to another risk enables you to achieve clarity and understanding
beyond risk analysis. For example, you might have to decide between
losing $1 million on a $40 million project or coming in a month late on a
critical project with a $40 million client. Although neither risk is
good, it might not be possible to respond to both.
Prioritizing risks also highlights when you are using too fine a level of
detail in your risk analysis. The process of prioritizing risks also
allows you to develop a sense of your project's and organization's level of
risk tolerance. Prioritization is effective only when you use
defined selection criteria.
To prioritize risks, confer with team members and use the following practical
approach:
When prioritizing risks, working as a team is an important, although challenging, task. Team members might often have different opinions about the impact or probability of a risk because the risk might not have an amount of money associated with it. For many risks, the impact and probability can be expressed only in relative terms.
Avoid planning response strategies during this step.
What Is Risk Response Planning?
Risk response planning is deciding what, if anything, should be done with a risk. It is the assignment of actions to contain, reduce, or eliminate risks. Risk response includes:
According to WWPMM, these are the strategies that you can use to respond to risks are:
The PMBOK has a similar definition of risk response strategies, but calls them Avoid, Transfer, Mitigate and Accept. Accept means you are willing to accept the consequences of the risk.
Risk Triggers
An important part of defining the risk containment plans is risk triggers. Risk triggers are indicators that specify when an action must be taken. If the trigger event happens, then initiate the action plan.
Examples of triggers and action plans include:
Effective triggers:
Risk Response Options
Starting with the prioritized list of risk events, you must select the best risk response option. Following is a list of the options you might use for the identified risks:
Transfer risk. Determine if the accountability, responsibility, and authority for the risk belongs to the project or to another organization. Transfer implies ultimate accountability, responsibility, and the authority to expend required resources to mitigate the risk that exists outside of the delivery organization. Transfer requires the acceptance of risk by the other party. In risk transfers the risk is not removed from the project, it should still be tracked as a project risk.
Options for transfer include transferring the risk to a sponsor or supplier through terms in an agreement, to an IBM organization in a business unit not connected with the project through formal written documentation, or to an IBM organization in the same business unit as the delivery team through informal written documentation.
For risks not transferred, determine who will own them within the project.
Insurance. When you have coverage, use it to cover the cost of the risk event.
Contingency. In this type of response, you make the decision to use monies set aside for risk management reserve or risk contingency reserve. Using management reserves is an alternative to increasing the price of the project to the sponsoring organization. Generally, establishing and using management reserves is controlled by the delivery organization policy.
Contingency is a reserve held outside of the project cost baseline for future situations affecting project cost or schedule. It is not held for specific risks but at an aggregate level. The risk contingency reserve is held inside of the project cost baseline and used to address future situations affecting project cost or schedule.
Mitigate. In risk mitigation,
you take steps to lessen risk by lowering the probability of a risk occurrence
or by reducing its effect on the project. In risk contingency planning,
you develop a plan for defining actions to be taken if the risk occurs.
Factors to Consider When Planning Risk Response
Many factors influence the selection of a risk mitigation strategy, including:
Impact of Different Risk Options
Some project elements can be affected by different risk options. For example:
What Is a Risk Management Plan?
In the risk management plan, you document the risks you have identified, the response plans for each of those risks, and the actions required. This document changes during the project as risks change, as you execute the response plans, and as conditions change.
As the project manager,
you should look at this document regularly to determine whether any new risks
should be added or old risks removed. You should also determine whether
any of the response plans require change.
Your risk management plan is one of the key documents that a project reviewer
checks for content and for evidence of updated activity.
Completing a Risk Management Plan
Various pieces of information exist for each risk event. In addition, a variety of formats are used to create the risk management plan. The following page shows a completed risk management plan in table form. To fill out this simple example, you would list the risks in the following columns:
You should use the more comprehensive plan format that WPMM provides. This plan is available at the WWPMM Web site.
Rank. Enter the priority rating for the risks in this column. The most severe risk (that is, the risk that poses the greatest danger to the project) is ranked number 1.
RIN. To help track the risks, assign each risk a risk identification number (RIN). As the project proceeds and new risks are identified, the priority ratings change but the RIN number remains the same.
Source of Risk. Enter when and where the risk was identified.
Risk Event. Provide a description of the risk in this column.
Response Strategies. Use this column to document the response strategies that you have defined to reduce the severity of the risk to the project. After completing the column, consider whether these strategies could be used together or if they are mutually exclusive.
Sample Risk Management Plan Rank RIN Source of Risk Risk Event Response Strategies Action Required 1 2 Architect Review Insufficient time to perform product verification test
2 4 WBS review by lead tester No test suites available for required open systems standards
3 1 WBS Incomplete UCD analysis results in user interface problems
4 5 Contractual requirements/product plan assumptions Use of new IPD methodology will delay schedule
5 3 Company objectives and plans Elements not fully integrated into OS public build
After Completing the Risk Management Plan
After the risk management plan is prepared, complete the following tasks:
Risks are Being Mitigated Key
This key is often misunderstood. It is not about whether a project has risks; every project has risks. Rather, this key is about determining whether a risk management plan exists, whether the plan has been communicated to team members, and whether it is being actively used. Here are some criteria for assessing the Risks are Being Mitigated key.
So the Risk key is about whether the risk management is working properly. While other keys could be red, this key could still be green because risk management is working as it should be working. On the other hand all other keys could be green and this key could be red if this is the only key needing corrective action.
Here are the signs to look for:
Healthy Signs
The risk plan is documented.
Test-it-first tactics are used.
Unhealthy Signs
The sponsor or team members ask, 'What risks?'
All-or-nothing tactics are used.
On some projects and with some companies, the idea is to go the quickest way, which is almost always the riskiest way. Do not take a risk lightly, and be prepared to mitigate your risks.
It is recommended to proactively be looking for risks in the areas of the other 6 keys using their Risk Management Process to support this.
How does the risk key impact the other keys?
Risk management is about being proactive and dealing with issues before they become problems. Without risk management, all of the other keys will be affected. When creating your risk management plan, it is important to identify and analyze risks that may impact all of the keys. Use the Seven Keys as a checklist when creating and updating your risk management plan.
Why Is Risk Management Important?
I believe there are risks associated with every project.
Using risk management helps me to
prevent problems from occurring or to reduce their impact on my project when
they do occur.
Risk management helps to prevent surprises and the need for crisis
management.
The chart on the page represents
the triple constraints for projects.
If one element changes due to a risk event, the other two
elements are affected. Risk management helps me to reduce the impact of
those risk events on each of the three constraints, helping to make my projects
more successful.
The risk management plan enables me to define what needs to be done to reduce
the risk of the project and to track each of those actions. Because risk
management is an iterative process, it is important to look at the risk
management plan at each of the major milestones or checkpoints. If you
never look at the risk management plan after you initially create it, the plan
will not help you.
Estimating a project involves predicting the amount and cost of resources required to execute the project. Using an estimate enables you to develop an idea of the final, required budget.
When estimating, follow these guidelines:
Ask if this is an independent estimate or if it will be developed with detailed scrutiny of every aspect of planning and estimating work.
What Is an Estimate?
WWPMM defines an estimate as an assessment of the likely quantitative result based on experience or historical data from previous projects, if any.
You will usually estimate the number of labor hours, labor costs, and other costs (material, travel, and so on.) for the project. The following terms are a key part of estimating and are used throughout this module:
An estimate should ideally include some indication of accuracy. Early in
the project planning, you wont know all the details about the project, and so
your estimates will have a wide accuracy range around them, perhaps as much as
50% under to 100% over. But as you plan the project in detail, you
should be able to produce estimates with a narrower range of accuracy, say 5%
under to 10% over.
What Is an Estimate? (continued)
To summarize, an estimate is:
However, an estimate is not:
Items to Include in an Estimate
An estimate should include all of the following items:
An estimate must include
all of the items in the previous list. If you are asked to lower your
estimate because the price is too high, what are your options? To lower
the price, you can reduce the scope, reduce risk and associated contingency, or
possibly reduce resource at the expense of schedule. Or, management can
decide to lower the profit margin.
An estimate is just that--an estimate. The only perfect estimate is the
one done after the work is completed.
The degree of accuracy of an estimate depends on the phase of the development
cycle that you are in. In the concept phase, the estimate has a lower
degree of accuracy than in the planning phase.
Reasons for Estimating
There are many reasons for estimating, including:
Many cost and schedule overruns can be traced back to a poorly developed estimate. Even when the overrun is the result of poor execution, a good estimate should have included allowances for this. For example suppose you estimate the project at a low cost by using fewer resources and shorter durations than required, and then the project is authorized and you are the project manager. You find yourself committed to the project with insufficient resources and insufficient time. The probability of completing a successful project is very low. However, if you had done the estimate had been done correctly, it would have included sufficient resources and an appropriate schedule.
Characteristics of an Estimate
The characteristics of a good estimate are the approximate judgments of the effort, cost, and time to perform a task or a project. Specifically, an estimate:
When Should an Estimate be Completed?
As noted previously, there are different points in a project when an estimate should be prepared, reviewed, or revised. These include:
You must develop the WBS
before preparing an estimate, even if it is only the preliminary version.
If you take over a project, you should prepare a new estimate or validate an
existing estimate. Review staffing and skill levels stipulated in the
project proposal and assumptions. Questions you should ask include:
Are the skill levels correct? Are the hours assigned for tasks
realistic? Do the hours include time for holidays, vacation, and any
other downtime?
The estimate should also be reviewed or reworked if an assumption becomes
invalid. Always document your assumptions as part of the estimate.
This helps explain an incomplete set of data and also helps make your estimate
more credible and complete.
Steps in the Estimating Process
The steps in the estimating process are the following:
Click each step to read a description of it.
Estimating Considerations
When you prepare estimates, be sure you know the language used
in estimating (for example, if you are talking about elapsed time, ensure that
the sponsor is not talking about work time). This can make a major
difference in the resulting costs. Estimates vary, depending on whether
the task is based on effort or duration.
Most tasks that have work to be done as a criterion for completion are
considered effort-based.
The task has a total amount of effort that must be completed in order to finish
the task. This might also be referred to as staff effort
and is generally expressed in person hours. As a rule, the more resources
assigned to the task, the shorter its duration.
Some tasks are duration-based. The duration is constant regardless of how
many resources are assigned to the task. (For example, the duration
required for a slab of concrete to dry is the same regardless of the number of
people watching it happen).
Another key difference is elapsed time as opposed to working time. Elapsed
time is the total number of days over which the task occurs.
This is also called calendar time, and is usually expressed in calendar days,
weeks, or months. Working time is the actual amount of time available for
work. Working time takes into account the working hours
or time available for project team members. It does not include time away
from the job such as vacation or holidays. Working time is usually
measured in working hours divided by days or weeks.
Availability is the time a staff person is available and
willing to work. This is usually measured in work hours per day or
working days.
Productivity is a relative measure of work in a time
unit. Different skill levels have different productivity rates. You
must determine which productivity should be used for the estimate. The
safest approach is to use an average productivity of 80%.
Keep in mind that the time it takes to complete a task depends on both
availability and productivity.
Estimating Terms
The following terms are used in estimating and productivity measurement.
Click each button to read the definition of that term.
Effort
This is the numer of labour units requiered to komplete a task. I tis usually measured in stakk hours or person-hours. When the numer of stuff and thein working time or availability is taken into accounut, an average produktivity should be assumed.
Level of feffort (LOE)
This describes the activities that are necessary to support a project that cannot be Schedule.LOE activities are usually measured in start hours dor the duration of the aktivity.
Duration
This is the numer of work periods, excluding holidays or other nonworking periods, requiered to komplete an aktivity or other project element. Duration is usually expresed in work days or work weeks. There are 2 tyoes of duration: contiguous (work time that is not interrupted) and interruptible (work time that might be interrupted). Duration is determined by first establishing the estimated effort requiered for a task, then diving by a utilisation factor.
Estimating Terms (continued)
It is very important that you, as the project manager, estimate your time and share with your team the LOE estimates you have made concerning their work. This work should consist of items such as preparing procedures, meeting attendance, preparing status, obtaining equipment, and so on. Most project managers add 10% to the total effort for administrative items that team members must accomplish in addition to their WBS tasks. If you show the team your estimates for LOE and assure them that time has been added to the estimate for these items, you are in a better position to defend the estimate to management and to explain why 10% is a required amount of time in addition to the WBS items. You can also request help from team members and assure them that they have time to do this task because 10% LOE was built into the schedule.
The difference between effort and duration is that effort relates to the number of labor units required to complete a project activity, whereas duration relates to the number of work periods required to complete it. When you are preparing a schedule, specific resource availability and productivity might affect actual duration.
If the work you are estimating is repeatable and historical data is available to support the productivity of the various groups you are using on your project, then you can use the historical data to project reliable and accurate productivity factors for your current project.
What Is Utilization?
Utilization is the amount of time a
full-time equivalent (FTE) can be used on a project. An FTE is not
necessarily a specific individual but can be the combining of two or more
individuals whose efforts equal one work day (for example, eight hours) or a
portion of a work day. In reality, personnel are not available full time,
eight hours per day, 40 hours per week, 52 weeks per year.
Utilization rates are affected by the time required for education, vacation,
holidays, administration, personal time off, travel, and sick leave.
Utilization is usually expressed as hours per day, but can be expressed as a
percentage of duration: for example, 50% of the time during a two-week task.
Availability indicates whether the resource can be used during a
particular period on your project. Remember, good people are usually in
high demand. When creating an estimate, you need to determine the impact
that vacation time has on a task to which key personnel are assigned.
What Are Utilization Factors?
Utilization factor describes the amount of
time a full-time equivalent (FTE) can be used for the length of the
project. An FTE can be a specific person or a combination of different
people's hours to equal a work day. You should rely on utilization
factors to arrive at high-level planning estimates. Estimates should
constantly be refined based on assumption validations, changes to requirements,
and use of actuals.
The following is an example of how the utilization factor is calculated and the
effect it has on your project.
Therefore, for this example, the effective utilization factor is 77%, or 134 hours per month.
Example of Utilization Guidelines
The following table shows the approximate percentage of time that an FTE is available, based on project length and hours per month. Generally, the shorter the project, the higher the utilization level.
|
Project Length |
Hours/Month |
Utilization |
|
|
||
|
3-6 months | ||
|
6-12 months | ||
|
>12 months | ||
Example of a Duration Formula
If you have a task that is estimated to take 120 hours and you
are paying $10 per hour, you need to budget $1200. However, the person is
available only 75% of the time. Over a 6- to 12-month project, the
project manager must allow for vacation, holidays, sickness, training, and so
on. Assuming an average productivity of 80%, the duration is calculated
as follows:
Duration = Effort/Productivity
Availability
= 120/.80 = 150 = 200
hours
.75
.75
= 200 hours
8 hours/day
= 25 days (versus the original 15 days (120/8))
* Note: The formula to calculate the duration is the following: Duration equals effort divided by the average productivity and then divided by the availability of the person.
Methods of Estimating
Estimates are developed with a number of methods or a combination of methods as follows:
Top-down. A top-down estimate (defined in detail later in this section) is used in the initial stages of a project. A top-down estimate compares historical data with experience. This is sometimes called a guesstimate.
Bottom-up. A bottom-up cost estimate (defined in detail later in this section) involves receiving estimates from all estimators and then summarizing them into a cost estimate for the project. This method could involve inflated pricing as estimators add contingency to their estimate. Ask the estimators what contingency they used to prepare the estimate. If any estimator used utilization or availability factors, then you do not apply these techniques again.
Parametric. This measures the effort of a task. Parametric is defined in detail later in this section.
Analogy or comparison. This describes the comparison of similar projects.
Expert judgment. This is the information provided by a group or a
person with specialized knowledge and training.
It is important to know the type of estimate and its level of precision so that you are not overconfident or underconfident when you present your estimate to management. As stated earlier, estimating for a project is not done just once. It is done throughout the life of the project. You must determine the level of accuracy needed for your estimate. A plus-or-minus precision indicator is required to best ensure that the recipient knows the level of validity (for example, that the project will cost U.S. $1 million, plus or minus 25%). Each estimating method and type of estimate is used at different times in your organization.
Parametric estimate
The parametric estimate, wich was described, uses specic measures to estimate the effort requiered to komplete a task or to produce a work produkt. Examples are dollars per square foot.
The estimating unit (EU) is the unit defined by the team that can be measured and estimated. THe EU can apply to more that one task, but these tasks should be similar. Different factors can affect the task and can increase or decrease the effort and therefore, the EU. Too manu EUs can result in a methid that estimates individua items Tater than a large group of similar items. Examples of estimating units are lones of code, pages in a chapter, or numer of lessons in a vlase.
Analogy or Comparison Estimating
Analogy or comparison estimating is also called analogous estimating. It uses the actual cost of a previous, similar project as the basis for estimatinf the cost of the current project. Adjustments must be made to account for differences in performance, design, technology and opertaional characteristics.
I tis very important to consider the source and duality of analogous data.
Estimate Characteristics
The following chart
illustrates the characteristics of the types of estimates and the various
methods of estimating.
|
Type |
Accuracy |
Use |
Methods |
|
Order of Magnitude |
Initial Concept entry |
Analogy / Comparison |
|
|
Budget |
Concept DCP, CRM-RFI, |
Analogy / Comparison |
|
|
Definitive |
Plan DCP |
Analogy / Comparison |
Key points to remember about estimate characteristics are:
Order of magnitude is a top-down estimate. It is used during the
formation of the project for initial evaluation and during the IPD concept
phase. It is also called concept, preliminary, or feasibility estimate.
Order of magnitude should provide estimating accuracy of minus 25% to plus
75%. It usually errs on the plus side.
Budget is a more detailed analysis. It is a mixture of firm and unit
costs for labor, materials, and equipment. Budget is developed from more
detailed project analyses and is used in the concept Decision Checkpoint
(DCP). Budget is also called the design, control, or appropriation
estimate. Budget should provide estimating accuracy of minus 10% to plus
25%.
Definitive is a detailed, bottom-up estimate used for proposals and
evaluations. It is prepared from well-defined data and specifications,
and is used in the IPD plan and DCP exit phases. Definitive should
provide an estimating accuracy of minus 5% to plus 10%.
DCPs are structured project reviews with specific entry and exit criteria, used
to measure the progress of a project.
Validating Estimates
Validate all estimates before you consider them complete. Use the following checklist to validate an estimate:
Rules of Estimating
The rules of estimating
focus on honesty. If you want an honest estimate, each element of this
list has to be honest.
The rules of estimating are:
Remember that these rules are fundamental to estimating. You must follow
them if you want to develop a valid estimate.
Cost Estimating and Budgeting
Estimating a project
involves predicting the amount and cost of resources required to successfully
execute the project. Many approaches can be used to estimate.
Because each approach has advantages and disadvantages, you might need to
combine approaches to obtain the best estimate for the project. By using
the estimate, you can develop a better understanding of the budget required.
Estimating is done as early in the project life cycle as possible and is
normally repeated a number of times throughout the life of the project as
changes in the project dictate. Estimating is initially done during the
planning process after which a budget is agreed to as the baseline for the
project plan. Estimates can be redone or refined throughout the project
based on performance or on the need for redefining and replanning that results
from project change requests.
Estimating is the process of identifying the 'should cost' for each
project task and activity. If estimating is performed at the higher
levels in the WBS, this higher-level estimate must eventually be broken down to
the task and activity level to effectively manage the project execution.
These tasks and activities then combine to form the 'should
cost' for the project's life cycle. Although the estimate is not
the project management schedule, it is used as input to the project management
schedule when finalizing the project plan.
Budgeting is the
allocation of the 'should cost' over the time period required to do
the work. The estimate provides the 'should cost' for the task
or activity, but further analysis is necessary to determine the specific time
period needed to perform. Time periods can be hours, days, weeks, or
months depending upon the complexity of the task, activity, or work
product. After the 'should costs' have been spread out over
time according to when the work is to be performed, the project manager must
develop a time-phased cost baseline that becomes the plan-of-record cost to a
work package. It uses the estimate to determine how much money is
allocated to each work package. This enables project managers to develop
a financial measurement baseline that is then used to track and control the
execution of the project.
Documenting your estimates and assumptions about the estimates is a very
critical and mandatory part of the project. It is the sole responsibility
of the project manager to ensure that it is done.
This module shows you how to use estimating within project management and
provides the terms and formulas used within estimating. After you
complete this module, you should be able to define what an estimate is,
determine what should be estimated, recognize the difference between
effort and duration, describe specific types and methods of estimating, discuss
the estimating process, and describe what is involved in generating and
validating an estimate.
Cost Estimating and Cost Budgeting Defined
As stated earlier,
estimating is determining the resources (labor, equipment, and facilities)
needed to complete the project. One reason for creating a project budget
estimate is to provide a basis for tracking and managing project costs.
Specific tasks within the estimating process are cost estimating and cost budgeting.
When approved, the budget is placed under change control and is the basis for
establishing the financial measurement baseline of the project.
When all of your costs have been defined and the project budget has been approved, all of the costs should be input into the WWPMM Financial Plan work product. The description and template for the work product can be found along with descriptions and templates for all work products at the WWPMM Web site.
Terms Used within Cost Estimating and Cost Budgeting
Become familiar with the following terms, which are used within the cost estimating and cost budgeting processes:
Questions to Ask When Cost Estimating
When you are preparing a cost estimate, ask the following questions:
Not taking the time to make good estimates can affect several of the keys. First, work and schedule will not be predictable, as deadlines will be missed. The delivery organization benefits key will likely go red as spending increases and the project goes over budget. How do the sponsor and key stakeholders react when the project is late and over budget? Now your stakeholders lose their commitment. And at the end, the project will not be successful and deliver the business benefits that were expected. Why Are Estimates Important?
Think about your own project experiences. Have you worked on a project where the estimates were not prepared properly? Can you recall what effect poor estimates had on stakeholders and the project staff?
Estimates are important because they establish the basis for
planning and establishing a baseline for tracking. I have learned that
almost every overrun of cost and schedule can be traced back to the failure of
an estimate. Without a good estimate, it is almost impossible for you to
have a good project.
Estimating is more than determining a magic number. Estimates combine all
of the elements of the puzzle that comprise the total project, as shown in the
following graphic. If any one of these elements is not considered, the
resulting estimate is invalid, and an invalid estimate leads to a difficult or,
potentially, a failed project.
Project Schedule:
A schedule is any plan structured on a time dimension, including a project management schedule, financial plan, operating schedule, and staff schedule.
Schedules are key management tools for tracking and communicating the progress of a project.
You can use a project schedule to:
What Is a Schedule?
A schedule is any plan structured on a time dimension,
including a project management schedule, financial plan, operational schedule,
and staff schedule. Schedules are key management tools for tracking and
communicating the progress of a project.
A project management schedule is a road map of a project that states the
duration and sequence of events and activities; more specifically, it states
what will be done, when it will be done, and who is responsible. It is
composed of estimates, work products, activities, and tasks from the WBS, and
resource information. A schedule also contains the planned dates for
performing activities and meeting milestones and defines how the current
project interlocks with other projects.
A project management schedule can be represented in a variety of ways.
Three of the most common are precedence diagrams, Gantt chart, and milestone
chart. These are detailed later in this lesson.
As the project manager, you use a project schedule to:
Scheduling Terminology
This section lists terms and definitions used in project scheduling:
Including Level-of-Effort Tasks in the Schedule
You must include all project management and technical tasks in the schedule. Some of these are level-of-effort (LOE) tasks, which are activities that are not easily measured in terms of discrete accomplishments. LOE tasks that should be listed in the project schedule include, but are not limited to:
As you schedule these LOE tasks, you must validate your estimates to ensure that you have included enough time. In doing this, you might find that you need additional time; if so, you must include it. If you do not, and the contract is a fixed-price contract, the cost will be higher in the end.
Displaying the Schedule
Precedence diagrams, Gantt charts, and milestone charts are
ways of displaying the project schedule. They can be created with most
project management software tools.
Click the buttons to view each type of diagram:
Precedence diagram
A precedence diagram, is one type of project network diagram. It shows the relationships between activities.
Grantt Charts
A Gantt chart, is useful for viewing planned project activity versus actual activity.
Milestone Charts
A milestone chart, is
often used for communicating with upper management.
Note that, until resources are actually assigned,
these views are only estimates, not actual schedules. The project manager
must use the right view for the right purpose.
Description of a Project Network Diagram
A project network diagram consists of a series of project activities arranged in a logical flow. It is the basis for a project schedule and provides a consistent framework for planning, monitoring, and controlling the project. Every work element from the WBS is represented in the network diagram, and only WBS work elements are represented there.
The precedence diagram includes only the elements from the lowest level of the WBS. It does not include rollup activities (1.0, 2.0, and so on.).
From WBS to Project Network Diagram
The WBS contains all of the activities necessary to complete
the project, but it is not a scheduling tool. The project network diagram
is a scheduling tool that shows the predecessor and successor relationships
between activities from the WBS.
One difference between a project network diagram and a WBS is that a
project network diagram contains start and finish nodes. Nodes are
essential because they provide anchors for the software algorithms for team
members who use software packages such as Microsoft Project.
When you combine all of the products and activities from the WBS, the project
network diagram, estimates, and resource requirements, you will have a
clear road map of the what, when, how, and who of the project.
To create a project network diagram, list the activities or tasks for the
project. These become the activity nodes in your project network
diagram. Ask the project team if they have activities that need to be
finished before other activities can start. Record the order in which
activities need to be completed. Working in this way, continue
identifying and then drawing the dependency relationships to create a network
diagram of the project.
Remember that a project network diagram is built only from the level or levels
in the WBS in which work is assigned and accomplished. WBS activities are
represented as a sequence flowing from left to right on the diagram. An
arrow going into the left side of a node indicates the start of a task.
An arrow leaving the right side of the node indicates the end of a task.
Elements of a Project Network Diagram
The elements included in a project network diagram are:
Guidelines for Creating a Project Network Diagram
Follow these guidelines for creating a project network diagram:
An example of a loop is as follows:
With the fourth step, the process starts to repeat itself.
Creating a Precedence Diagram
Three common methods of creating project network diagrams are the precedence diagram method (PDM), the project evaluation and review technique (PERT), and the critical path method (CPM).
Many project managers use the PDM to create a specific type of project network diagram. In a PDM diagram:
Although a precedence diagram has specific information, such as predecessor,
successor, and duration, written on each box, it is different from a conventional
flow diagram. It cannot, for example, contain loops, because this would
require moving backward in time.
Each box in a precedence diagram represents an activity at the WBS work element level; these boxes are called nodes. Nodes are linked by arrows that show the nature of the relationship between predecessor and successor activities.
Creating a Precedence Diagram (continued)
In the following chart, notice that activity 1.1 is the
predecessor to activity 1.2. This means that activity 1.1 must be
completed before activity 1.2 can start. Following this logic, activity
2.2 cannot start until both activities 1.2 and 2.1 are both completed.
Note that there is no precedence relationship between 1.2 and 2.1, so there is
no arrow connecting them.
PDM diagrams are frequently confused with PERT charts. You can tell them apart because PERT charts contain multiple time estimates for each node, whereas PDM networks have a single time estimate for each work package. PERT charts also use activity on arrow (AOA), where the arrow represents the activity and the node is the event; for example, the start or finish of an activity.
PDM Network Relationships
The activities in a PDM network diagram have one of three types of precedence relationships:
Click each button to read a description of that type of relationship.
Finish-to-Start Relationships
The FS relationship is the
most common precedence relationship. In an FS relationship, one activity
must finish before another activity begins. In the following example,
activity 1.2 cannot start until activity 1.1 is finished.
Examples of FS relationships might include:
Finish-to-Finish Relationships
In an FF relationship, the predecessor activity must be completed at the same time as the successor activity is scheduled to finish. You might need to know how to build FF relationships if your sponsor is operating on a just-in-time basis or if you have no warehousing capabilities.
FF relationships are
important when two tasks must finish at the same time;
for example:
Start-to-Start Relationships
SS precedence
relationships are used in situations where one or more key activities must be
started at the same time so that a project can remain on schedule. An SS
dependency requires that the predecessor activity be scheduled to start before
or simultaneously with the successor activity. In the following example,
activity 1.2 cannot start until activity 1.1 has started.
These are examples of SS relationships:
Lead Time and Lag Time
Lead time and lag time are changes in precedence relationships
that direct a delay or acceleration in the successor task. Both are
formal ways to adjust the schedule.
Lag time is a delay imposed on the relationship between two
activities. For example, in a finish-to-start dependency with a
10-day lag, the successor activity cannot start until 10 days after the
predecessor has finished. Lag time is generally expressed as a positive
number because lag time adds to the overall duration of a series of
activities. Lag time must be counted when computing your schedule
duration.
Lead time is an acceleration of the successor activity.
For example, in a finish-to-start dependency with a 10-day lead, the
successor activity can start 10 days before the predecessor has finished.
Lead time is usually expressed as a negative number because it subtracts from
the overall duration of a series of activities.
An example of the use of lag time is adding one day to a six-day model airplane project schedule. After the first three-day activity, Glue Model (activity 1.1), is complete, one day of lag time is added to enable the glue to dry. Then the remaining three-day activity, Paint Model (activity 1.2), can be accomplished. The result is an overall schedule duration of seven days.
Lag time is not counted as part
of an activity's duration. Lag represents a fixed delay between the start or
finish of one activity and the start or finish of another.
An example of the use of lead time is the
subtraction of a week from an overall six-week schedule for creating a software
program. The first activity, Write Code, does not necessarily need to be
completed before the second activity, Write Documentation, begins. By
overlapping these two activities by one week, the overall schedule can be
reduced to five weeks.
Using the Precedence Diagramming Method
The first step in drawing a precedence diagram is to determine
the dependencies among the activities in your WBS. A good way to do this
is to put the title of each activity on a small piece of note paper. Take
all the notes and stick them on a large piece of paper or on a
wall. Along with members of the project team, work through all the
dependencies, putting them in their correct order. You will probably
change your mind several times and move the notes around. When the
activities are in the correct order, draw arrows between them denoting the
dependencies. This gives you the basic layout of your precedence diagram.
Take the time to ensure that the project team agrees on the layout of the
project activities.
When you have the basic layout of the diagram, write the estimated duration
of each activity in the middle of its box under the title.
Documenting the Values in Each Node
The boxes you created in the preceding paragraph are part of the standard format for the nodes in a precedence diagram. The activity name, WBS number, and activity duration are placed in the middle of the box. Four other values are placed in the corners of the box. These four values are:
Calculating Start and Finish Dates
Part of creating a precedence diagram is calculating the start and end dates for each activity. Two processes that help you do this are the forward pass and the backward pass.
Applying the Forward Pass
The forward pass is used to calculate the ES
and EF dates of all network activities. Here are the steps to follow.
The first activity starts on day 1 of the project; therefore that is the ES
date for that activity. In the following example, the first activity is
Mix Concrete. Its ES is day 1, the first day of the project.
Now you can calculate the EF for the first activity by adding the activity's duration to the ES. In this case, the duration is 6 days, so the EF is 7.
The ES for the next activity is the EF of the preceding activity. In our example, the ES for Pour Concrete is the EF for Mix Concrete, 7. Add this to the duration of the second activity, 4, to get its EF, 11.
By going through the entire diagram in this way, you will arrive at the project's EF, the earliest date the project can finish.
The formula for the forward pass is ES + duration = EF.
One point to keep in mind is that some activities have multiple predecessors. The ES is the earliest date that all the dependencies have been satisfied.
Applying the Backward Pass
The backward pass is used to calculate the LS
and LF dates of all network activities. These are the latest dates these
events can take place without affecting the finish date of the project.
For this example, assume that the LF of the activity following Pour Concrete is
15. To calculate the LS of Pour Concrete, take 15 and subtract 4, the
duration of the activity, to get 11.
The LS of Pour Concrete is the LF for Mix Concrete. To calculate the LS
for Mix Concrete, subtract the duration from the LF: 11 - 6 = 5. This
means that Mix Concrete can start as late as day five without affecting the
finish date of the project.
The LS calculation is LS = LF - duration.
Note that in the last activity of the project
the EF is the same as the LF. Using that
LF, you can start the backward pass.
Also note that the LS and LF numbers do
not equal the ES and EF on the bottom
path.
Lag and Lead Time in the Forward and Backward Pass
You might recall that lag time adds time to the schedule and lead time subtracts it. An example of lag time is waiting until the glue dries before painting a model. An example of lead time is doing two activities in parallel rather than in sequence to save time in a development project. You must take lag time and lead time in a schedule into account when calculating using the forward or backward pass to calculate.
In the following example, the EF
for Mix Concrete is 7. Using the forward pass, and with no lag time, that
would also be the ES for Pour Concrete as well. However, if you decided
to add 5 days to allow the concrete to cure (notice the arrow), the ES for Pour
Concrete becomes 12. The formula is EF + lag time = ES of the next
activity.
Using the backward pass in the following example,
you would subtract the 5 days of lag time from the LS of Pour Concrete to
get the LF of Mix Concrete. Lag
and Lead Time in the Forward and Backward Pass (continued)
Whereas lag time adds to the schedule, lead time subtracts from it. In the following example, it has been decided that Pour Concrete can start while Mix Concrete is being done. Again, notice the arrow. Using the forward pass, 2 days would be subtracted from the EF of Mix Concrete to calculate the ES of Pour Concrete. The formula is EF - lead time = ES of the next activity.
Using the backward pass in the following example, you would add the 2 days of lead time from the LS of Pour Concrete, 6, to get the LF of Mix Concrete, 8.
What Is Float?
There are two kinds of float. Free float, or slack, is
the amount of time a single activity can be delayed without delaying the ES of
any subsequent activities. Free float determines the pressure that one
activity puts on the next activity.
Total float is the sum of free float for each activity in a particular
path. It is also the amount of time an activity can be delayed from its
ES date without delaying the project finish date. Total float often
changes as the project progresses and changes are made to the project plan.
Project managers use total float to adjust schedules and resource
allocations. When it is used to adjust resource allocations, the process
is called resource leveling.
Total float is an important indicator of project status. If total float
is greater than 0, then slack time is available. If total float is 0,
then the situation is critical. If total float is less than 0, then the
project is already behind schedule or critically late.
Calculating Free Float and Total Float
Click each button to read the description and calculations.
How to Determine Free Float
Calculations for float time use ES, EF, LS , and LF values.
The calculation for free float, which again is the amount of time an activity can be delayed without affecting the early start date of the successor activity, is:
Free Float = ES (successor task) - EF (predecessor task)
In the following example, the calculation for free float between activity A and activity B is FF = 5 - 3 = 2. This means that task A can finish as late as day 5 without affecting task B.
Total Float and Free Float Example
Calculate the total float and free float for the following example. Remember that you must complete the forward pass and then the backward pass before you can calculate float.
The total float for tasks A, C, G, and H is 0. The total
float for tasks B, D, and E is 7: 8 - 1, 11 - 4, or 14 - 7. The
total float for task F is 8: 12 - 4.
The free float for tasks A, C, G, H, B, and D is 0. The free float for
task F is 1: 7 - 6, and for task E, 7: 17 - 10.
Remember that free float is time available between activities, and total float
is time available within an activity. Float can be used to determine
wether a project might be finished earlier by using resources that have time
available within a task or between tasks to aid those tasks with 0 float.
The tasks with 0 float are critical and must start on the ES date and finish on
the EF date, or your project will be late.
Characteristics of the Critical Path
As the project manager, you want to make the best use of your time. The critical path method helps you do that by focusing your attention on the activities that must start and finish on time or else the project will be late. All the activities that have zero total float are on the critical path. If any of them starts or finishes late, then the whole project will be late. Every project will have at least one critical path that runs from the Start node to the Finish node.
The critical path of a project is the longest path in the network; therefore, it determines the earliest completion date of the project. In the following example, the critical path runs through tasks A, C, G, and H. This path is the one with no float, and it is the longest path through the project. It represents the shortest time period in which the project can be completed: 19 days.
The critical path might
change as your project progresses; for example, if another path within your
project has a total float of 1 day and is delayed by 2 days, that path might
now become the critical path.
Sometimes a project has multiple critical paths. This can increase the
risk of missing the project's completion date because there is more than one
path that has no float in the schedule. If you do not know where the
critical paths are, the risk is much higher that you will not meet your
schedule.
In summary, the critical path is:
Validating the Precedence Diagram
So far you have been making mathematical calculations, and now you need to make sure the results are going to work in the real world.
Before you translate the precedence diagram into a schedule, you must do one final validation.
The validation steps are:
Ensure that your network is komplete and current
Have you correctly identified your critical path?
Should any tasks with large amounts of float be rescheduled?
Are there any danglers?
Become familiar with your network and analyze it
What risks are on the critical path?
Are there near-critical paths?
How much float is available?
What types of float exist on which tasks?
Ensure that your objectives can be met
How to Create a Schedule from a Precedence Diagram
The following diagram indicates that there are numerous inputs to the project schedule in addition to the precedence diagram.
Other areas you need to consider include:
As the project manager,
you first determine what must be done to complete each task; this means
identifying the necessary roles and the needed skills. Then you determine
who has the required skills and assign them to the appropriate roles. The
people assigned must have the skills necessary to fulfill these roles. If
they do not, you might need to add more people or change the schedule to allow
time for training.
The challenge is to coordinate all of these inputs to develop a schedule that
satisfies all the stakeholders.
Is there a complete set of roles for each task? If not, add roles where needed.
Checking
the Schedule
After generating the schedule, you must check
each input and assumption one more time to ensure that nothing has been
overlooked. Consider involving an outside person in the checking process.
The following questions will help you check the
schedule:
Checking the schedule usually requires several iterative passes.
If Your Schedule Is Constrained by Time or Resources
If your schedule is constrained by time or resources, consider the following options:
Types of Schedules
WWPMM uses two important
types of schedules.
A project management schedule defines the planned start and finish dates
for, and the dependencies between, all the work units for which the project
organizational unit is responsible. A project management schedule
contains all the technical work and all the project management work being done
by any reporting organizational unit one level below the unit in the
organizational breakdown structure (OBS).
An operational schedule shows how the work of a project organizational
unit is broken down into work items.
The purpose of an operational schedule is to:
A WWPMM work product description and a template are available to assist you in creating a project management schedule and an operational schedule. You can find these along with descriptions and templates for all WWPMM work products, at the WWPMM Web site.
Work and Schedule are Predictable Key
This key covers estimating
and scheduling, and is often the first key to become unhealthy on a project.
Sometimes problems in this key are due to poor estimation and scheduling
during the planning phase. But the root cause for work and schedule
problems are often found in other keys, such as the stakeholders lose their
commitment or the scope is not well understood.
Here are some criteria for assessing the Work and Schedule are Predictable key:
Healthy Signs
Everyone gives the same definition of finished.
Good evidence of control is available.
Slippage, when it happens, is predicted
Unhealthy Signs
Stakeholders and project team members cannot describe what finished means.
Controls are not evident, including poor plans and tracking mechanisms.
Slippage is a surprise.
This key is the traditional project management indicator of project health. It is otherwise known as 'on time and on budget.' The project team uses this early project health indicator to implement a correction in the course of the project.
What's the Value of a Precedence Diagram?
A precedence diagram is a terrific tool that helps me
understand my project, make sure I have
all the activities identified, and understand how they all relate to each other
and to the external
dependencies. As I'm going through the process, I always find additional
activities that I had
missed, and I go back and add them to the WBS. By working through the
dependencies, it
becomes clear what needs to be done first and what can be done later.
A precedence diagram is essential so that I can see how long it's really going
to take to finish this project. The critical path is the key element
here. That defines the longest path. If any of those activities
miss their targets, the schedule starts slipping. I have to have that
data to create my schedules and understand which activities have the highest
priority. Otherwise, I'm just guessing.
Why Check the Schedule So Thoroughly?
When the schedule is approved by the stakeholders, it becomes
one of the project's constraints, along with cost and scope. That means
that it has to be as accurate as possible. If the schedule is incorrect
but the scope is correct, I'm going to miss the dates, and the customer will
not be happy. In most cases, the project will also go over budget at the
same time.
A great precedence diagram doesn't guarantee a great schedule. I
find that I need to carefully recheck the assumptions that went into the
precedence and the schedule after I create them. I ask myself, Is this
schedule based on reality? Can we really do it?
Change management
Changes occur and cannot be ignored. Managing change is critical to the success of a project. Change management helps protect projects against scope creep, which occurs when the requirements baseline changes. As additional requirements are added to the project, the cost of the project increases and the schedule moves out.
When managing change on projects, remember the following steps:
What Is Change Management?
Change management includes
the processes required to control all of the changes that inevitably arise
during the course of a project changes that might jeopardize cost, revenue,
quality, or deadlines.
Managing change is critical to the success of a project. As stated
previously, executing change management might result in changes to one or more
of the project baselines.
A change request is defined as a request to change some document or
aspect of the project that has been placed under change control, or baselined.
Change management:
Change management contains the following:
Some tracking systems might include procedures for addressing changes that can be approved without prior review. If this is the case, these changes must still be documented and addressed so that they do not cause problems later in the project.
Types of Change
Changes might be technical or contractual as shown in the following figure.
Technical changes.
Technical changes result from the implementation of the solution.
Normally, the changes are generated internally and are within the scope of the
project. An example of a technical change is implementing a program that
automates test cases. This program helps improve the quality of the
testing.
Contractual changes result from changes in the terms and
conditions, the scope of work, the requirements, schedule, and costs.
Normally, contractual changes are externally generated and out of the project
scope. For example, the sponsor might ask IBM to include maintenance of a
system as part of a purchase agreement for the system with IBM.
For both technical and contractual changes, a formal change management procedure must be established.
What Is a Baseline?
WWPMM defines a baseline as the reference data on which
execution of project activities are planned and controlled. A baseline
consists of elements of the agreement and the project management plans. A
baseline might also be considered as the original plan, plus or minus approved
changes.
A baseline becomes formal after the involved stakeholders review and
approve it, then sign off in writing. After it is established, the
baseline is under change control.
Why Establish Baselines?
Changes occur in almost every project. Experience has
shown that without baselines, managing change is very difficult, if not
impossible. Unmanaged change can cause the scope to increase to the point
where the project is out of control.
Establishing a baseline helps you determine boundaries for the project,
including what is being developed, when it is scheduled to be delivered, and
how much it is projected to cost.
Required Baselines for Managing a Project
Although many types of baselines are possible, the three types that must be set for each project are:
Requirements, cost, and schedule are known as the triple constraints. They are interdependent; a change in one of the three has an impact on the other two.
The requirements baseline is established after all project requirements have been defined and documented and then reviewed and approved by the appropriate stakeholders on the project, including the project sponsor, who then must sign off in writing.
Baselines and Change Management
Changes do occur. Change management ensures that all
changes are documented and everyone is aware of the impact they will have on
all the baselines. Change management provides discipline regarding who
can provide or modify the baselines. Without this control, changes could
come from almost anywhere, such as senior management, sponsors, users,
suppliers, and technical personnel, and the project team might be expected to
implement them without regard for the impact on the project. Uncontrolled
baselines can lead to late products, low quality, and cost overruns.
Changes must be reviewed and approved before they are added to the
baseline. This process ensures that any potential problems are identified
before the change is implemented and that the change request is complete,
consistent, and feasible.
What Is Included in a Change Management Process
Many projects have
encountered serious difficulties because a formal change management process was
not established and enforced. Without a doubt, change management is one
of your key responsibilities as the project manager. Even a one-line
change could be extremely significant. That is why you always need to be
careful when managing change.
Given the importance of change management, you, as the project manager, must
ensure that the process for managing changes is clearly documented and
understood by all project stakeholders, suppliers, and the IBM delivery
team. This process must then be strictly enforced whenever the need for a
change occurs.
Change management includes a:
You must identify what baselines you will control, at what level of detail, how, and by whom. Each change to any of these baselines should be documented and follow the defined change management process. Many projects use a CCB for accepting, rejecting, or deferring change requests. The powers and responsibilities of a CCB should be well defined and agreed upon by key stakeholders and included in the change management plan. On some large, complex projects, multiple CCBs might have different responsibilities.
Establishing and enforcing a formal change management process is key to project success.
The Change Management Process Illustrated
The following figure shows the process that should be used to manage changes.
Steps in the Change Identification Process
The major steps in the change identification process are:
Estimate the complexity and the cost of investigating. For large changes, a quick assessment of their complexity and an estimate of the cost of investigating is done.
Approval or rejection. The change request is then reviewed by the CCB and is approved for a full impact assessment, rejected, or deferred. If the change request is rejected or deferred, it is logged, the reasons for the rejection or deferral are documented, and the change request is filed for possible future reconsideration. All interested stakeholders are informed of this decision.
Change investigation
The following steps are performed when investigating any change:
The change request is reviewed by the change control board and approved for implementation, rejected, or deferred.
If the change request is
rejected or deferred, the result is logged, the reasons for rejection or
deferral are documented, and the change request is filed for possible future
reconsideration. All interested stakeholders are informed of this
decision.
Change Implementation
If the change request is accepted for implementation, a change order is generated instructing the appropriate project personnel, including suppliers, to implement the approved change request or its alternative. In addition, all appropriate baselined documents are updated to reflect the change, including the possible revision of the contract with the sponsor and the supplier. The result is logged and filed, and all interested stakeholders are informed.
Generally, your approval signature and that of the project sponsor are needed before the change request proceeds to impact assessment.
You must ensure that the impact assessment considers the impact on schedule, costs, resources (hardware and software), personnel (including suppliers), documentation, logistics support, and the contract terms and conditions and performance.
Communicate the decision for each change request to those who need to know, including the originator of the change request.
The Change Request Form
Whoever wants changes, either the project team or sponsors,
must submit the request using a change request form. The change request
form describes the impact of the change on the project, including the cost of
the investigation and the cost of the change. The purpose of the form is
to minimize frivolous changes.
The form is used on both large and small projects and represents the minimum
documentation.
Example of a Change Request Form
The graphic shows a template of a change request form.
The Change Log
Use a change log to list
all changes, the owner or originator, and the status. The change log is a
WWPMM work product.
Typical Follow-Up Actions for Change Requests
If a change is:
Guidelines for Managing Change
Follow these guidelines for managing project changes:
How to Implement the Guidelines for Managing Change
IBM's policy is that all projects have change
management procedures in place.
You, as the project manager, must implement these
guidelines on every project in a strict and conscientious way. The change
management process must be executed and strictly enforced in order to maintain
control of your project.
The process of managing change should not be
complex. Problems arise, however, when project managers, in an attempt to
reduce bureaucracy, adopt an informal process to handle change requests.
Misunderstandings often result from informality. As project manager, you
might find that, because the project is committed to deliver a changed output,
you have to absorb the added cost involved and scramble to meet the old
schedule. Changes to your project might also affect projects managed
directly by the customer or other organizations. For these reasons,
change control is an important part of the project manager's job on every
project.
Think of all the bad things that can happen to a project if changes are not managed. And then think of how the Seven Keys will be negatively impacted. Scope will be unknown. Work will not be completed on time and on budget. Team members will not know what they are supposed to be doing. New risks will arise and existing risks will become more severe. And finally, stakeholders will be surprised when the deliverables do not match their expectations.
When analyzing each change request, determine how the change will impact each of the Seven Keys.
Why It Is Important to Manage Change
Have you ever been on a project where change was not managed well? Think about what the project manager should communicate to the stakeholders in order to successfully control the change management process.
Managing change is a critical factor in the success of a
project. Without a sound, well-understood, and enforced change management
process, the project will be out of control soon after it starts.
Change is inevitable. It will happen. You, as the project manager,
must be prepared for it and manage it appropriately. Your focus should be
on controlling the amount of change by ensuring that all changes that are of
benefit to the project are appropriately analyzed (including assessing
impacts), approved, communicated, and implemented in a timely, cost-effective
manner. At the same time, ensure that any proposed changes that are of
little or no value to the project are rejected.
The Project Management Body of Knowledge states that a project
manager will spend about 90% of their time communicating. Change
management is an area where it is vital to gather input from stakeholders and
communicate the decision about the change, whether it is approved or not, back
to the stakeholders.
In all but the simplest of projects, some change is essential. In
projects with an external sponsor or customer, changes can be an important
source of additional revenue and improved or enhanced deliverables.
However, too much change can impact productivity and ultimately can lead to the
project becoming out of control. You, as the project manager, must ensure
that this does not happen and that change is a positive, well-managed
process.
I encourage you to review the document Prevention Measures to Avoid
Troubled Projects, which includes a number of items relating to project
baselines and change management. This document is available at the Quality Assurance Web site.
Project control and execution
Project management is about planning, organizing, monitoring, and controlling all aspects of a project in a continuous process. Project control is an aspect of project management. Its focus is to define and execute appropriate actions to ensure the success of the project. Without good project control, the scope, costs, and risks increase and cause deadlines to be missed.
With project control, remember the following:
Project Management and Project Control
ISO 10006 defines project
management as the planning, organizing, monitoring, and controlling of all
aspects of the project in a continuous process to achieve the project's
objectives. Project control, an aspect of project management, is
defined as the process required to define and execute appropriate actions to
ensure the success of the project. The focus of project control is
monitoring, analyzing, and comparing planned results with actual results for
the purpose of predicting what might happen if current conditions continue.
Project control begins with clear objectives and emphasizes the achievement of
the project goals. It involves continuous monitoring of individual
project events and elements such as budgets and schedules. Without
good project control, the scope, costs, and risk increase and deadlines are
missed.
The Key Elements Required to Control the Project
Although tracking and controlling a project's overall performance is addressed directly in the WWPMM Tracking and Control domain, you must also focus on plans and procedures in the following key domains:
Four Steps of Project Control
The project control process, like many other project management activities, is an iterative process repeated many times throughout the life cycle of a project. Click each of the following buttons to read about the four steps in project.
Establish standards
You are responsible for establishing the standards by which the project will be measured as well as the processes that define how the project will be executed. This involves establishing key project control plans and the processes within each of the 13 WWPMM. Remember, these are iterative processes that you need to continually update.
As the project manager, you are responsible for executing these four steps. Regardless of the business processes that you follow, the project management processes are the same.
Observe performance
After you establish the plans, processes, and standards, you observe how the project is progressing. In this step, performance information is collected from several sources, including meetings, reports, briefings, letters, audits, and observations.
As the project manager, you are responsible for executing these four steps. Regardless of the business processes that you follow, the project management processes are the same.
Compare planned with actual performance.
When you have collected appropriate performance data on your project, you compare its current status with your standards and expectations.
This step answers two questions:
How is the project doing? And, if deviations from the original project plan have occurred, what caused the deviations?
Take corrective action.
Finally, you decide what if any corrective action should be taken. This step involves activities such as revising plans, reallocating resources, and changing the way the project is organized or managed.
If You Do Not Control the Project
If you do not control the project, the scope of the project will increase. This almost always adds cost to the budget and time to the schedule. In addition, you will not know whether your project is on schedule.
It is generally more difficult to meet a schedule than to move a schedule. As a result, if you do not know that you are on schedule and are not focused on staying on schedule, chances are you will not be on schedule.
Poor control often also results in:
What Is a Project Control Book?
The project control book (PCB) is a
collection of project documentation that establishes the framework for
controlling the project. WWPMM defines the PCB as 'the organized
folder, or set of folders, where the agreements, plans, procedures, and records
supporting the project management system are kept, referenced, and
cross-referenced, as appropriate, to help in retrieving the information needed
at any point in time for project management purposes.' In Integrated
Product Development (IPD), the PCB is called the integrated project file,
or IPF.
The Purposes of a Project Control Book
The PCB helps you keep the project documentation up-to-date.
It is a central library of project standards and procedures and the output
associated with those standards and procedures. It provides a reference
document of outputs used to measure project team performance and up to date
information about the progress of the project. It also defines a standard
way to produce, issue, and maintain project documents. The PCB becomes
useful historical information, captures intellectual capital, and is required
in some business plans.
The PCB is used as a basis for reviews and audits, as an information repository
for team members, and as a tool for other project managers. It is
important that you have all the latest information and status in your PCB.
Contents of the Project Control Book
To decide what should be in the project control book (PCB), start with the list of project management plans and procedures for your project. This is an example of such a list:
You do not have to include all these items in the PCB; in fact, because each
project is different, you might not have all these plans and procedures, or you
might have others.
When you have decided which plans and procedures to include in your PCB, list the outputs from each of those plans and procedures. For example, if you include progress tracking procedures, progress reporting procedures, and financial plans in your PCB, you would also include their outputs. The outputs from progress tracking might be updated schedules and time reports; from progress reporting, they might be contractual status reports and variance analyses. From financial plans, they might be expense reports and financial reconciliation reports. By including these in the PCB, you give everyone the latest view of the project.
Contents of the Project Control Book (continued)
According to WWPMM, if your project uses the following work products, their outputs should be kept in your PCB.
Click each button to read the list of items for each work product.
Procedures
Plans
Records
Issue Management and the Issue Log
Problems and issues can affect the control of any project. A problem is a cause for concern that is within the project manager's domain of control. The project manager has the tools to fix a problem.
An issue is more generic than a problem. An issue is a cause for concern on a project. Many issues arise during the course of a project. Most of them are solved by the work team as part of their daily work or by the project manager. Some issues, however, are beyond the scope of responsibility of team members and the project manager. These issues affect the project manager's area of control, but the project manager lacks the necessary authority or tools to fix them. A project manager must either escalate or delegate those issues to the area of control that can provide a solution.
Each issue should be documented in an issue document, a WWPMM work product that describes the issue in detail and provides a complete history of its progression through analysis and resolution. There is also a WWPMM work product for the issue log, which lists all the issues that occurred and required recording during the life of a project, including the owner, due date, and status. Here is a sample issue log.
Notice that each issue has
an owner and a target date for completion.
In most cases, the best way to resolve an issue is to be sure the issue has an
owner and a target date for completion. At each status
meeting, ask the owner to report the status of the issue.
The column labeled priority
(p) helps you to prioritize the
work. Additionally, there is a date opened column. This is for
reference purposes, so that you can see how long the issue has been open.
Issue control has much in common with change
control. Both processes involve documenting the change or issue,
assigning responsible parties, and tracking the change or issue through to
resolution.
How to Control the Project
Follow these general guidelines for controlling your project and monitoring your project plans on a day-to-day basis:
Tracking and Controlling Risk
After you analyze the
risks and assign actions to mitigate them, you must track the risks and keep
the risk plan current to control them. This might result in adding,
changing, or removing containment actions.
The project manager and the team must:
Risk tracking and control is a PM subdomain in the Risk Management PM domain. For more information, go to the WWPMM Web site.
Reacting to Risk
Reacting to a risk includes executing the necessary risk responses and closing the risk as appropriate:
Metrics
A metric is a tool
for measuring the progress of a project. The primary purpose of a metric
is to enable you to monitor and communicate project status.
There are no standard metrics that apply to all projects. You must
determine your sponsor's preferred metrics and choose the most appropriate
metrics for your project.
Metrics must relate to something that can be tracked and measured. In
most cases, you will be measuring actual results and comparing them with
planned results; for example, measuring test cases actually completed and
comparing them with test cases planned to be completed by this time.
Good metrics must have other characteristics too. They must be
planned for, they must span the life of the project, and they must be
understood by the sponsor, the team, and the project manager. Some
examples of metrics are:
Earned Value Analysis
Project managers are constantly looking for methods or tools that will provide specific, timely, and accurate project information to support their decisions. Earned value is one of the methods for gathering such information and monitoring a project's performance. It serves as an indicator of project status, and helps determine the project's progress. The term itself refers to a specific measurement, the budgeted cost of work performed.
Earned value analysis is the process of comparing, in terms of earned value, the project's actual performance against its planned performance. It can be calculated in hours or in dollars, and it can be calculated cumulatively or used to measure subprojects individually.
Earned Value Terminology
Earned value has its own vocabulary. One way to understand and remember its terms is to think of them in relation to the questions that often arise in project management and review. Earned value measurements are designed to answer such questions.
The Earned Value (EV) is the amount of work actually accomplished, stated in terms of the budget assigned to accomplish that specific scope of work. EV answers the questions, How much has been accomplished against plan? or How much work has been performed and verified? PMI's old term for EV was Budgeted Cost of Work Performed (BCWP).
The Planned Value (PV) refers to the costs
that should have been incurred for the work that should have been completed to
date. The PV answers the question, What is the planned cost? The PV
must be established before the EV can be meaningful. (To use earned value
correctly, the PV, and therefore the dollar amounts, must be allocated across
the project's WBS, with dollar amounts associated with WBS elements.)
PMI's old term for PV was Budgeted Cost of Work Scheduled (BCWS).
The Actual Cost (AC) is the total cost incurred for the work accomplished during a given period of time. AC answers the question, How much did it really cost to perform the work? The AC can be higher than the EV if there are more resources applied to a task than planned, or if a task takes longer than planned. PMI's old term for AC was Actual Cost of Work Performed (ACWP).
Senior management personnel are concerned with facts and how they are interpreted. It is important to make sure the work is actually completed. Project managers often make the mistake of saying, 'I'm 90% complete.' By focusing on PV, EV, and AC, you can avoid such pitfalls.
The following measures are used in earned value forecasting to predict the costs at the end of the project based upon the currently available information:
Budget at Completion (BAC) is the estimated total cost of the project at completion, or what the
project should cost if your planning is accurate. It answers the
question, What is the baseline cost of the project? Notice that the BAC
is the sum of the PV. Be aware that events sometimes occur that disrupt
your plan and either decrease or increase the BAC.
Estimate to Complete (ETC) is the projected cost to complete
the project from a specified point in time. It answers the question, How
much will it take to finish? Establishing an ETC needs to be determined
periodically after establishing a BAC. The same data, analysis, and
investigation that are used to establish the BAC are required for an accurate
ETC. The only differences are that the starting point for the ETC has
moved forward in time and more data is probably available.
Estimate at Completion (EAC) answers the question, 'What will it cost when it is finished?' Calculating the EAC requires two data points: the AC and the ETC.
A Pictorial View of the Earned Value Components
The following graphic shows, you can see how the Planned Value curve in green compares to the Actual Cost curve in blue and the Earned Value curve in red. The goal is to have the Actual Cost curve and the Earned Value curves both match the Planned Value curve. In this example, you can see that at the end of the first month, the Earned Value (actual work completed) was below the Planned Value, and the Actual Cost was above the Planned Value. This graphic clearly shows that the project is behind schedule and over budget.
Earned Value Analysis
Earned value is a key indicator of overall project
status. It facilitates an objective assessment of variance between plans,
budgets, and performance and enables a common understanding of the amount of
work actually completed. Earned value is a moment-in-time metric.
Researchers have found that two of the components of earned
value, schedule variance and cost variance, are valid indicators of
performance after 20% of the project is underway. At that point, these
two metrics can give you an accurate total picture of the project.
Both schedule variance (SV) and cost variance (CV) are used to pinpoint
potential project problems, which can then be investigated further.
Positive numbers are generally good and negative numbers are usually bad.
A positive SV means the project is ahead of schedule; a positive CV means the
project is under budget. Be aware, however, that these indicators cannot
isolate activities on the critical path.
SV answers questions like, What is the difference in value between what was
accomplished and what was scheduled? The formula for SV is:
SV = EV - PV
Notice that EV is used in the equation. In real life, SV is a reflection of what has been accomplished, the EV; versus what was planned, the PV. It does not, however, consider what has actually been spent.
If the SV is positive, then more work has been completed than
what was scheduled, and the project is ahead of schedule.
If the SV is negative, then more work was scheduled than has been performed,
and the project is behind schedule.
The Cost Variance (CV) answers the question: What's the difference in value between what was accomplished and what was spent to do it?
The formula for CV is:
CV = EV - AC
Again, notice that EV is used in this equation. CV is a reflection of what has been accomplished, the EV; versus what was actually spent, the AC. It does not consider what was planned to be done.
If the CV is positive, then the costs were less for the actual
work than what was budgeted, and the project is under budget.
If the CV is negative, then the costs were more than budgeted for the work
actually accomplished, and the project is over budget.
Percent Complete is a
measurement that compares the value of the work accomplished with the total
amount of work that needs to be done. The formula for Percent Complete
is:
Percent Complete = EV / BAC
Percent Spent is a measurement that compares the money that
has been spent with the total amount of money available. The formula for
Percent spent is:
Percent Spent = AC / BAC
Delivery Organization Benefits are Being Realized Key
The delivery organization manages and completes the work on the project. It includes groups from IBM and any of the client's staff working on the project. A successful project will reflect well on the customer's staff, too, and lead to new opportunities. Profit is just one aspect of this key. Other aspects include IBM's reputation in the marketplace, the ability to perform future projects more efficiently, and staff development.
Here are some criteria for assessing the Delivery Organization Benefits are Being Realized key.
Besides the earned value analysis, look for these signs:
Healthy Signs
People feel they are learning.
People are willing to invest in the project.
Good press is being created.
Unhealthy Signs
Good staff members are not available.
Negative remarks about performance.
Why Is Tracking so Important?
Methodical tracking of projects is the only way I can keep my projects
on schedule. I have to know what's happening so that I can anticipate the
problems before they impact my project. I have weekly status meetings
where we discuss the status of the project compared to the plan and review all
the issues and concerns. I document the issues and track them through
resolution. That's the only way I can be sure each issue gets resolved in
a satisfactory manner.
Another tool I use is earned value. I think it's difficult to know if I'm
on schedule. If the project makes its first milestone on time, I know
only that the milestone is on schedule. But what about all the other
activities that are happening at the same time? By using financial
measurements like earned value, I can see what areas are behind or ahead of schedule
and where I'm overspending. I know how much money has been spent, and I
can calculate how much money I should have spent. It's a great tool for
getting an objective view.
As a project manager, the worst thing that can happen to me is that I get
surprised. If there's a problem that I wasn't aware of and I didn't make
the appropriate changes to mitigate it, it will impact the cost, scope, or
schedule of the project. I need to understand what's happening on the
project so that doesn't happen.
Remember, even good projects are not green on all keys all the time. But successful projects always address their project health issues promptly and effectively. On the other hand, poor projects generally have one or more keys go red early, and then stay red for the rest of the project.
Points to remember about the Seven Keys:
Points about using the Seven Keys:
Project management review
Project management reviews help ensure that a project is progressing on schedule, and within budget, and is meeting the requirements. A project management review can indicate if and where a project is in trouble. There are different kinds of reviews, but here are the kinds of topics that are typically covered:
Why Conduct Project Management Reviews?
Project management reviews
provide opportunities for you to report project schedule and budget status,
highlight project accomplishments, identify problems, escalate issues, and
elicit management support. The main purpose of a project management
review is to provide general guidance to you as the project manager with an
objective assessment of a project's health. Reviews should be conducted
by an independent group of skilled reviewers outside of the project who can
view the project objectively.
Different Types of Project Management Reviews
Different types of project management reviews are held based upon the timing of the review. Project review types are:
In addition, WWPMM defines the following types of health reviews:
As the project manager, you must not rely totally on prescribed reviews but should exercise judgment in determining which reviews are necessary and when they should be held to make the project a success.
Decision Checkpoint Reviews in IPD Projects
Integrated Product Development (IPD) is part of the Decision Checkpoints (DCPs) process. Although the IPD community does not have a quality assurance (QA) organization, they are still required to execute QA tasks. DCPs are structured project reviews with specific entry and exit criteria that measure the progress of an IPD project. DCPs are held, in some cases, as a baseline review. DCPs are conducted at the following points in a project's life cycle.
Reviews in the CRM Project Management Process
Global Services has a QA organization that conducts project reviews at the following points in a project's life cycle.
QA Process During Solution Design
The QA process starts during opportunity management and continues through proposal development ending with price release.
The steps are:
Reviews in the CRM Project Management Process (continued)
Global Services has a QA organization that conducts project reviews at the following points in a project's life cycle.
QA Process During Solution Delivery
Project management and delivery conduct reviews. The steps are:
Topics You Should Cover in a Project Management Review
Before the review,
you should make arrangements with the review team leader to set the schedule
for the review. Typical activities to plan for a smooth review include:
the project manager's presentation, interviews with key project members
(including subcontractors), interviews with key customer project team members
and the project sponsor, project documentation analysis, and review debrief
with the project manager.
In the typical project management review, you have an opportunity to present
your view of the project at the beginning of the review. You should cover
the following topics that overview:
Key Questions to Answer
In the project review
process, the key question is, Where are you? The reviewers want to
understand where you are today. There is also a need to look forward, to
predict the future. You can do both of these by using the earned value
(EV) indicators to determine where you are relative to the budget and the
schedule today and where you will be at the end of the project. EV
status and predicting indicators are detailed in Module 9, 'Change
Management.'
The following key questions help to determine the health of a project.
The EV status indicator or EV predicting factor associated with each question
is included.
Some of the other key areas that the reviewer will want to investigate are risk
management and change control. Reviewers want to examine your risk
management plan to be sure you are keeping it updated and implementing the
mitigation plans. They will also want to examine your change control
process and evidence that you are using it and following your process.
The Review Findings
After the reviewers have reviewed the documentation and talked to the team members, they will want to analyze the information and prepare a report of the findings. The reviewers might prepare the report on the same day as the review or they might leave and send you the report later. You are expected to establish a plan to address any concerns or problems noted in the report.
Avoiding Problems
Troubled projects have a significant impact on IBM's
profitability and extensive negative impact on the IBM reputation for high
customer satisfaction and quality service. The most frequent and common
denominator in troubled projects is the IBM proposal and the performance team's
failure to understand and follow IBM internal processes and guidelines.
Projects also break down because of failure to follow project management
discipline procedures, not because of the inability to resolve the technical
problems.
By following the steps in the IBM Global Services Worldwide Quality Assurance
Management Discipline (WWQA/MD) procedures, you can identify and avoid many
potential problems. Available documentation supporting the implementation
of WWQA/MD can be found on the Quality Assurance Web site.
The Prevention Measures to Avoid Troubled Projects white paper
contains a description of root causes of troubled projects that are frequently
encountered, along with suggested prevention measures. The white paper
links the root causes of troubled projects to various categories or project
phases, such as organizing the project or risk management. The white
paper is based on the findings of project management reviews and on the
analysis of troubled projects. The following attachment is the Prevention
Measures to Avoid Troubled Project white paper.
You can access this white paper from the Quality Assurance Web site.
Seven Keys to SuccessTM
Suppose you are asked to review two projects.
Which project are you most interested in reviewing?
The first project. With its HUD all green, it is likely the HUD is not telling the whole truth and there are surprises to be revealed. In the second project, the problems are visible and are being dealt with.
The Value of Independent Project Management Reviews
As a project manager, I look at project management
reviews as an opportunity to show my
peers what I am doing, to learn something, and to get some help where I need
it. I don't have
the opportunity to compare notes with my peers very often, and project
management reviews
give me that opportunity. When I review the project management review
findings, I always
learn something new.
Project management reviews are also a great opportunity to get some support to
help me solve problems I might have that cannot be solved any other way.
Don't wait for external QA reviews to report urgent problems! On one of
my projects, I could not get the skilled resources I needed; they were not
available. After QA identified the lack of resources as a problem, the
priorities were changed and I was able to get the resources I needed.
Preparing for the project management review takes time. But the
preparation is usually updating documents that should have already been updated,
getting those final approvals, or filing the latest status reports. All
of that work needs to be done anyway, and the project review just forces it to
be done sooner.
Project Closeout
At some point, every project comes to an end and either succeeds or fails. The process of closing the project ensures that a number of items are addressed and completed as part of the project life cycle.
Completing these items is not simply housekeeping, but a process that is critical to providing good documentation for use in future projects.
When closing projects, remember these steps:
When Is a Project Closed?
Just as views differ about the project life cycle in IBM,
different opinions exist about when a project comes to closure. For
example, in the Brands business area, a project is considered finished when the
product is withdrawn from the market. In the Services business area, a
project is considered finished when all contractual commitments have been met,
the sponsor has accepted the delivered system, and the agreements with the sponsor
and the suppliers have been closed.
Sometimes, closing the project can be quick and straightforward. Other
times, it can be a long, extended process. In many Services projects, the
sponsor is reluctant to let IBM close the project because the sponsor has
concerns about running the system. Sponsors typically want to
retain the IBM delivery team and the suppliers for as long as possible.
Actions Required for a Successful Project Closing
Closing the project is the
process of reviewing all the documentation and agreements for the project to
ensure that they are complete and that all the commitments have been met.
Closing the project also includes reviewing the project to identify lessons
learned and the intellectual capital that should be documented for others' use.
The following figure is from the WWPMM work pattern, C3: Manage end of project,
in the Closing work pattern group.
The purpose of closing a project is to ensure that each of the following items has been completed:
The customer satisfaction survey has been completed by the customer or the sponsor.
The lessons learned have been collected and documented, as part of the project evaluation report.
The sponsor agreement has been closed.
Project Closing Terms
The following terms relate to closing a project.
Administrative closure is generating, gathering and disseminating information to formalize project completion. In the administrative area, all the project documentation must be completed and sent to the appropriate reciepients. IN addition, all the assets must be either returned to their owners or nominate as candidates for the Intellectual Capital Management database.
Closure documentation is communication between the sponsor and the delivery organisation or between the delivery organisation and a sipplier that acknoledges the agreement id complete. Closure documentation provide evidence that all terms of the agreement have been satisfied and all work has been completed.
The project evaluation report is a document created at the end of the project that highlights key points to be gleaned from the project, including lessons learned, intellectual capital and reusable materials.
Project Closing Activities
Project closing activities
must be planned and budgeted much as they are in other phases of the project
life cycle.
The major closing activities are:
Questions to Ask at the End of a Project
Questions that you should ask at the end of the project include the following. Of course, many of these items should be an ongoing focus throughout the life of the project.
Documents Required for a Successful Project Closing
To close a project, you
should collect updated copies of the sponsor and supplier agreements, any
amendments to the agreements, the latest project status reports, and the asset
inventory for the project.
After this information is collected, you and the members of your team who have
not yet been released from the project should prepare the project evaluation
report and oversee the release of the project assets from the asset inventory
back to the asset owners.
The project evaluation report contains the following sections:
The project evaluation
report generally applies to the overall delivery project, but it can be created
at any level in the project organizational breakdown structure
(OBS).
This report is typically created at the end of the project by the project
manager. However, it can be created at any time during the execution
phase. For projects of long duration, it is recommended that the project evaluation
report be created at the end of each phase of the project or conclusion of a
major milestone.
You create the project evaluation report by soliciting feedback from various
project stakeholder groups, such as project team members, the sponsoring
organization, suppliers, or IBM management. Review findings and
project documentation can also be useful sources of input.
Project Manager's Responsibilities
You, as the project
manager, must focus on the following closeout responsibilities:
Assess the terms of agreement and the completion of all commitments.
Release the technical environment.
Identify and release technical environment elements, such as office space,
computer installations, and related software. Equipment or space needed
for warranty support can be left in place after the project closes.
Obtain sponsor feedback.
Obtain information about the sponsor's areas of satisfaction and dissatisfaction,
then document this information and use it as input to the lessons learned.
Assess the lessons learned.
Determine the key lessons learned on the project, document them, and suggest
improvements for future projects in the project evaluation report.
Close out the sponsor agreement.
Perform the administrative closure of the sponsor agreement. This
includes generating, gathering, and disseminating information to formalize
project completion and closure.
Submit the intellectual capital.
Submit all intellectual capital generated on the project, including lessons
learned, the WBS, project definition reports, and any other related
documentation to the ICM AssetWeb. Current and future projects will
benefit from your experience.
Final Project Meetings and Reviews
Final project meetings and
reviews include:
Project review. Conduct a project review with the sponsor shortly
before the project ends to ensure that:
Lessons learned meetings. To identify key lessons on the project,
conduct lessons learned meetings with the internal team, the sponsor, and your
suppliers. How to conduct lessons learned meetings is discussed in
the 'Lessons Learned' topic of this module.
Final internal review. After the project is closed, conduct a
final internal review of the project to identify and submit any intellectual
capital developed on the project.
Documenting Lessons You Have Learned
Lessons learned on a
project are very valuable to delivery team members and members of current or
future project teams. It should not be necessary for every project
manager to make every mistake. A database of lessons learned can help
project managers learn from each other's experiences.
This information is documented in the project evaluation report, which becomes
part of the organization's historical database for the project.
Accessible to other project managers, a lessons learned list is a valuable tool
in any organization.
Lessons learned are not necessarily negative. They can describe a way to
do something better, faster, or more efficiently. You, as the project
manager, should document lessons learned as soon as possible after the lesson
is experienced, while the memory is fresh and most likely to be accurate.
When deciding what to document, remember that the lesson:
Examples of Lessons Learned
A few examples of lessons learned are:
To make these lessons more relevant and of true value, expand on them.
Gathering Lessons Learned
Start gathering and documenting lessons learned from the beginning of the project. At the beginning of the project, identify and document the lessons that you hope will be learned from the project and the intellectual capital that should be created. These might include:
Lessons learned should be recorded as soon as possible after the lesson is
experienced. As the project proceeds, you should keep an ongoing list of
lessons learned so that you will not lose any. In addition, you should
solicit inputs for lessons learned from delivery team members, suppliers,
sponsors, and key stakeholders.
It is very effective for all of the project managers to share their lessons learned in a respository that is accessible to everyone. There is no reason why all the project managers need to make the same mistakes.
Conducting a Lessons Learned Session
Toward the end of the
project, conduct a lessons learned meeting. The output of the meeting
will be a list of the lessons learned for inclusion in the project evaluation
report.
Invite all the participants on the project. Ask each to bring a list of
what went well, what did not go well, and lessons that each learned.
On some large projects, you might want to conduct multiple meetings or a
separate meeting with the suppliers and another meeting with the IBM team.
The following is a sample agenda that works well.
Agenda
The ICM Knowledge Management Process
The purpose of knowledge management is to leverage global intellectual capital to IBM's competitive advantage. As a project manager, knowledge management can:
The PMKN is a community dedicated to leveraging the body of knowledge to
achieve efficiencies and effectiveness in project execution. Intellectual
Capital Management (ICM) is part of the total knowledge management process.
In the ICM process, IBM project managers identify reusable products, processes,
and lessons learned on a project and submit them, normally during project
closing, with submission forms to the ICM AssetWeb, an IBM Global Service
centralized system for knowledge sharing, collaboration, and intellectual
capital management.
Adding intellectual capital to the ICM AssetWeb is very important.
Reading and using the information is just as critical. By using the
information already provided, you can improve your project management skills
and learn ideas for improving your project. Access the information in the
ICM AssetWeb as you start each new project and whenever you have a question or
issue needing the ideas of others. The probability is high that another
IBM project manager in a similar or related project experienced the same issue
and documented the actions taken to solve it.
Ensure that the material you submit as intellectual capital is also documented
in the project evaluation report for your project.
What Is the ICM Database?
The ICM database is owned
by IBM Global Services. It is a Lotus Notes team room that can be
accessed from Lotus Notes through a portal or a Web site. To access the
database using Lotus Notes, you must be a registered user or be an IBM Global
Services employee. To access it through the Knowledge Network portal, you
do not have to be registered nor do you have to be an IBM Global Services
employee.
The ICM database is divided into knowledge networks, which are called
subcategories in the portal. All the intellectual capital relative to
project management is located in the PMKN.
Instructions for Accessing the Project Management Knowledge Network
You can access the PMKN through the ICM AssetWeb. Instructions are available at the PM/COE Web site or at the knowledge portal for conducting searches and submitting material.
To access the PMKN from the PM/COE Web site:
To access the PMKN through the knowledge portal:
Seven Keys to SuccessTM
When gathering lessons learned, it is a good idea to review your Seven Key HUD status reports.
The Seven Keys can help you learn from your mistakes so your next project will run more smoothly.
Documenting Your Lessons Learned
The pilot for the training subproject has been completed
successfully. The pilot completed with $30,000 over budget, but only two
weeks later than planned. The software vendor was also two weeks late, so
the overall project schedule was not affected by the late pilot.
The executive director has accepted the training course because of the positive
comments he received from his staff, who are now using the course as the system
is being rolled out.
Your Assignment
It is time to document the lessons you have learned on this
part of the project. As a student going through this case study, what did
you learn that you will use on the job? One example might be to use the
WWPMM work product for the Project Definition document for your next project or
perhaps do a complete closing on your current project. Create a list of
six to eight lessons learned.
Attachments
No attachments exist for this assignment.
Check Your Work
No 'Check Your Work' assignment solution exists for this module.
Why
It Is Important to Close the Project
If your project is not closed properly,
significant legal, warranty, asset management, and financial implications to
IBM can result. Closing your project is the final step in what
everyone hopes has been a successful project.
I once had a project that I never took the time
to close. I had moved on to the next project and felt I did not have time
to do what I considered 'paperwork.' I had not verified that
the commitments had been met, and I did not update the documentation. As
a result, that project haunted me for months. The customer felt that the
project had not ended, and continued to call me constantly to ask for
things. As time passed, it became increasingly difficult to remember the
agreements and status of the project. Because I had not taken the time to
update the documentation, I did not have the documentation as backup when I
needed it. What had been a very successful project became a nightmare.
The customer grew increasingly unhappy.
Dont forget the Delivery Organization Benefits
key. I believe significant benefits are realized from gathering and
documenting lessons learned. When I am getting ready to start a new
project, I go through the lessons learned that our team has accumulated for the
last several years. Every time I do, I find something that I can use to
make this new project better. Most of the time my findings are simple
suggestions that helped clarify an issue. A terrific example, one that
served me well at one point on a project, was to ensure that the sponsor and
the other vendors were using the same word processor to facilitate review of
project documents. Although this compatibility had already been specified
for my project, seeing the same information in a lessons learned reminded me to
ensure that this compatibility was properly addressed.
When closing the project, take care of your good
people. Recommending awards or having a final thank you celebration can
make a team feel good and more willing to work for you again. A good
project manager knows the importance of locating and keeping employees with
good skills. Do not lose team members to another project manager who has
been more appreciative. Whenever I make an effort to say thank you to my
team, I find them willing to work with me again.
Project management tool suite
IBM project management toolsuite
IBM rational protofolio manager is IBMs strategis tool for enabling enterpride project management. It is a Web-enabled tool with a common repository that supports key project management activities for all stakeholders
Project Control BOOK (PCB) is a Lotus Notes-based tool for storing, accessing and managing project management work products.
GS Risk is a risk management roll that has been designed specifically for IBM internal use.
Program Operations Support Tool (POST) is a program management tool., A program is a group of related projects and other activities managed in a coordinated way to achieve a common long-term objective.
Engagement Support Environment (ESE) is a Lotus Notes tool that automates the use of IBM Global Service Method.
DocumentFactory (DF) is a tool that facilitates creation of standardized documents in the Lorus WordPro and Microsoft Word formats.
IBM Rational portofolio manager documents, status reports, financial data, project exceptions, expense reporting
Project control book
GS risk
Program operations support tool (POST) is the concept of program management
Engagement support environment
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 4502
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
