Each exam item (a question
with its possible answers) has at least two references to standard books or
other sources of project management. Most of the questions reference the PMI A
Guide to the Project Management Body of Knowledge (aka the PMBOK Guide).
The Project Management
Framework embodies a project life cycle and five major project management
Process Groups:
1.
Initiating
2.
Planning
3.
Executing
4.
Monitoring and Controlling
5.
Closing
Mapped to these five process
groups are nine project management Knowledge Areas:
1.
Project Integration Management
2.
Project Scope Management
3.
Project Time Management
4.
Project Cost Management
5.
Project Quality Management
6.
Project Human Resource Management
7.
Project Communications Management
8.
Project Risk Management
9.
Project Procurement Management
The processes of these knowledge areas are
described by their inputs, tools and techniques, and outputs. The PMBOK also
emphasizes the interaction and interdependence between different process
groups. For example, the outputs from one process may be used by one or more
other processes as inputs.Key Project Management Definitions
Project:
A project is a temporary and unique endeavor
undertaken to produce a unique product or service. It consists of a
set of coordinated and controlled activities with specific start and
finish dates. It is undertaken to achieve an objective that is
documented in terms of specific scope requirements, time, cost, and
resources. Operations, such as manufacturing, and projects differ
primarily in that operations are ongoing and repetitive, and projects
are temporary and unique.
Subprojects:
Projects are divided into subprojects for
control purposes. A subproject is a set of work units assigned to a
single person or unit that is used to divide the project into more
manageable components.
Program:
A program is a long-term endeavor undertaken to implement a business's strategy or mission. Program management involves coordinating multiple related projects to implement the business's goals. A program typically is longer than a single project. A program might have a specific set of goals, or it might be broadly defined and evolve over time as the business or organization develops.
Project Management:
Project management is the application of
knowledge, skills, tools, and techniques used to manage projects for the
purpose of meeting or exceeding stakeholder objectives and
expectations. Project management includes the planning, organizing,
monitoring, and controlling of all aspects of the project in a
continuous process to achieve its objectives.
Project Phase Overview
Projects are divided into phases for tracking and control purposes. Phases are a collection of related activities needed to attain a major milestone.
Project phases typically conclude with a management, sponsor, or quality review of the accomplishments versus the committed plan. This reduces the overall project risk by ensuring that the project is on track at key milestones as it progresses through its life cycle. In large and complex endeavors, phases might be treated as separate projects.
Assessing and Validating Opportunities
Market Planning
Market planning activities can be grouped into three phases: Market Definition, Capability Assessment, and Investment Prioritization and Management.
Assessing and Selecting Opportunities Overview
Portfolio analysis uses a common assessment method to make investment decisions based upon customer buying behaviors. Portfolio analysis compares new business opportunities with current offerings and then chooses the most attractive opportunities to implement based upon profitability and alignment with the organization's strategy. Portfolio analysis might also deselect a current market segment and then discontinue or sell off the investment. There are two types of selection methods: numeric and nonnumeric.
Profitability Measures
Profitability measures are used to assess the financial return of various opportunities that help business decision makers. Project managers should be aware of which profitability measures are used to select their projects because these financial expectations tend to follow a project throughout its implementation. Common profitability measures include these examples:
Currently, project managers need to understand the business drivers that lead to the selection of some projects and the rejection of others. Even though you may not be involved in assessing and validating new market opportunities, you need to be familiar with the methods and terminology that are used so you can converse intelligently with marketing and financial professionals and your clients.
Some people use payback period when selecting projects: the quicker the payback, the better the project. However, this simplistic technique does not factor in the time value of money. So don’t use it. It is better to use a net present value or internal rate of return approach, which does factor in the time value of money.
An agreement documents a plan to exchange services, solutions, and resources between parties. An agreement might be an external contract or an internal agreement:
The agreement defines each party's commitment to a project by establishing the rights and obligations of a buyer and a seller.
The agreement ensures that the completion criteria, pricing, and settlement of any future disputes are agreed to by both buyer and seller.
The base terms and conditions establish the agreement framework within which the project is carried out, but they do not describe the deliverables of a particular project. Terms and conditions are usually defined in a base agreement that is already in place before a particular project starts. The management of the base agreement is usually outside the scope of the project manager's responsibilities, but it might be appropriate for the project manager to participate in negotiating the base terms and conditions.
Transaction Documentation
The transaction document formally defines the key aspects of a particular project's products or services. A typical transaction document is a Statement of Work (SOW). For large, external projects, it might be appropriate for experts to assist with the negotiations and for a senior manager from the delivery organization to lead the negotiations. When the parties belong to the same enterprise, the agreement is less formal. For example, a simple Document of Understanding (DOU) might be sufficient documentation. In either case, the agreement might include or refer to additional, more detailed documents, such as a specification for the solution.
A Statement of Work (SOW) is a binding statement of products and services that the seller provides to the buyer. Some of the items included in an SOW are key assumptions, buyer and seller responsibilities, schedules, project completion, and charges. Here is a sample of a Statement of Work.
Contract Management Roles
Project managers must be aware of the contractual relationships used in their projects. Most projects have just one sponsor and one or more suppliers. Internal suppliers should perform their contract obligations with the same rigor and discipline as external suppliers. The following graphic shows the contract roles of the sponsor, delivery organization, and the suppliers.
Contract Types and Risk
It is important to understand the differences between the common contract categories and types because each type has its own risks for the buyer and the seller.
Fixed-Price (FP): In
an FP, the buyer pays the seller a set amount, so the seller takes a
risk that the project costs might be more than the buyer's payment.
Cost-Reimbursement (CR): In
a CR, the buyer reimburses the seller for the seller's costs. The
supplier continues to bill the buyer, whether the project's objectives
are met or not, so the buyer takes the greater risk. A common type of
contract within the CR category is the Cost-Plus contract (CP). A CR
contract adds an agreed amount of the profit that the seller will earn.
The profit might be fixed or be an incentive that is based upon the
supplier's performance. Buyers usually avoid a cost-plus-fixed-fee
contract because of the high financial risk assumed by the buyer.
However, a CR contract might be appropriate in situations where the
buyer expects many changes before final specifications are defined.
Time-and-Materials (T&M): In a T&M, the buyer reimburses the seller for the labor and materials provided. The labor hourly rates and material price usually include the supplier's profit. A T&M contract is much like a CR contract. In a T&M contract, the supplier continues to bill the buyer, whether the project's objectives are met or not (except for unit price contracts). So the buyer takes the greater risk. Some common types of contracts within the Time-and-Materials category are Level-of-Effort (LOE), Unit Price, and Indefinite Delivery, Indefinite Quantity (IDIQ).
In a Level-of-Effort (LOE) contract, the seller provides a uniform level of activity over a specific period of time. In an LOE contract, the supplier continues to bill the buyer at a set amount of effort over the duration of the contract, whether the project's objectives are met or not. So the buyer takes the greater risk, but the amount of effort is capped at a set amount.
The Unit Price and Indefinite Delivery, Indefinite Quantity (IDIQ) contracts are like an FP contract. They commit to a fixed-unit price for high quantities of the product over a given period of time.
Contract Payment Options
There are different options for contract payment. Project managers need to be aware of how the payment options affect the project's revenue projection and financial management. The value of money tends to decrease over time, so the later the payment, the less it is worth. The Net Present Value (NPV) calculation is used to determine the value of payments in the future.
Factors in Choosing Contract Payment Option
Payment options are subject to all types of contract conditions. It is imperative for the project manager to understand these conditions and factor them into the decision-making process. The following factors affect contract payments:
Words and Phrases to Avoid in Agreements
Some words and phrases should be avoided when writing agreements. These words and phrases are either ambiguous or they imply a greater commitment than intended. Avoiding these words and phrases helps to reduce possible problems with the customer later in the project life cycle. The following examples are sensitive words and phrases to avoid in an agreement:
Words to avoid
all
guarantee
minimize
always
immediate
most (used as a superlative)
assure
instantaneous
never
best
insure
secure
ensure
largest
shall
every
least
warranty
exceed
maximize
will
fastest
meet
Suggested replacements for some of the words to be avoided
address increase should can many should not could may security-enhanced
designed to
most (used to indicate majority)
security-rich environment help reduce
Phrases to avoid
acceptable response time
error free
normal conditions
any number
etc.
sufficiently large sample
as necessary
fully guaranteed
time is of the essence
as required
highest quality
to your full satisfaction
best efforts
mutually satisfactory
without any problems
better than
Country-Specific Considerations
In addition to the general list of words shown, some country-specific situations are to be avoided in international engagements.
The purpose of a Request for Proposal (RFP) is to solicit bids from multiple suppliers for products or services.
An RFP contains information about the customer's needs, proposal due date, and evaluation considerations. The RFP needs to be clearly defined to ensure that suppliers will respond with proposals that fit the business need. Procurement plays an important role in the RFP process of choosing suppliers for your projects. Procurement professionals are trained to avoid the many pitfalls that can have significant legal and financial implications. Procurement maintains a list of prequalified suppliers who have a history of performing well on past contracts. When qualified, suppliers do not have to go through the same degree of rigor and detail as an unqualified supplier. When preparing an RFP, carefully prepare your requirements, deliverables list, and the completion criteria, and then work with Procurement to guide you through the RFP process. The following graphic shows the typical structure and content of an RFP.
After an RFP is received by the potential suppliers, they prepare a proposal to submit to the customer. The RFP process is a competition between suppliers to gain the customer's business. Each supplier submits a formal proposal with the most competitive solution to meet the customer's need. Although each proposal must be competitive, they must also be achievable. After the customer selects a supplier, the proposal becomes the basis of the contract.
While proposals are being written, a bidder's conference might be held. This is a meeting between the buyer and the potential bidders to make sure that all have an understanding of the work requirements. Sellers can ask questions about the work. The buyer documents all the questions, and then the answers are shared with all the potential sellers.
After the proposal due date, the buyer assesses all the proposals that were submitted by the suppliers. The buyer uses several steps to evaluate and filter out unsuccessful proposals. First the proposals are checked to ensure that they meet the basic instructions in the RFP. Then, the remaining proposals are evaluated from a technical aspect and the supplier's ability to manage the proposal to a successful completion. The cost is evaluated against the value that each remaining proposal provides to the customer. The last step of the evaluation is to select the winning proposal and to notify the bidders who were not chosen.
TIPS: Set Your Client’s Expectations
It is important to begin managing client expectations early in the project. Because of the desire to win business, we may underestimate the complexity, costs, and time required for solutions. Therefore, you should include experienced staff in the early discussions with the client. Avoid the temptation to over promise and under deliver.
TIPS: Use the Contract Type Appropriate For the Work
I try to avoid fixed-price contracts, unless the project is short and relatively simple. Unless the scope of the project is defined in detail, the chances of a fixed-price contract completing on time and within budget are slim.
If possible, break down large projects into phases that are bid separately. Only give a firm price for the next phase of the project to be performed. For example, if there is no detailed design specification, use a time and materials contract on the requirements validation phase. Then you can offer a fixed price on the design phase.
Another concern of mine is whether the client has the resources, skills, infrastructure, and time to support the project. Before bidding a major project, I assess client readiness and develop an action plan with the client to address the concerns. If needed, add a post-implementation support task to keep the new solution running while the client’s staff is being trained to support it.
One last word of advice - Don’t ever work on a project without a contract!
Understanding Project Roles and Relationships
Because the authority of the project manager depends on the organizational structure, the project manager must understand and work within that structure. The project manager must be sure there is an approved Project Charter and that the project management system is documented in a Project Management System Summary. The project manager must identify all stakeholders and be aware of all project stakeholder perspectives. The project manager is responsible for blending these into a systematic approach that will achieve the goals of the project.
Project roles and relationships are often redefined as the project progresses through its life cycle. The previous graphic shows that roles and relationships must be understood throughout the project life cycle.
Successful Project Managers
The project manager identifies potential stakeholders early in the project and continuously checks for additional stakeholders throughout the project. Project stakeholders are those individuals and organizations who are involved in or might be affected by project activities. Stakeholders vary from project to project, but stakeholders usually include the project team, suppliers, delivery organization management, and the project sponsor.
The following graphic shows some of the stakeholders that a project manager might identify on a project, such as suppliers, management, and other business units.
The project sponsor is one of the most important stakeholders that the project manager should identify. The project sponsor plays an important role on the project. The sponsor must be committed to the project and have a personal stake in the project's success. A project sponsor might be internal or external such as a customer or a commissioning body. The sponsor is an individual who has the authority to perform the following responsibilities:
For the stakeholders, sponsor, the project team, and end-user representatives, the project manager is the single point of contact for communicating the project status and project decisions. The project manager plays multiple roles and must bring the project team members together and lead them toward successfully accomplishing the project's objectives. The project team might face many challenges, such as geographic separation and cultural differences. The project manager helps the team to overcome these hurdles. The project manager is ultimately responsible and accountable for the success of the project. On large projects, the project manager might delegate responsibilities to subproject managers and other team members.
The project manager role is demanding and requires a variety of technical, leadership, and management skills. Good "soft" skills are essential for a successful project manager. Project managers need a combination of management and leadership skills.
Successful Project Managers - Responsibilities
he responsibilities of a project manager are summarized in the following list:
Successful Project Managers - Soft Skills
Successful project managers exhibit the following behaviors:
Project Charter
How do we know that a project officially exists?
AProject Charter
is a document that summarizes a sponsor's request to form a project to
fulfill a business need. Project Charters are created at the beginning
of a project and formally recognize the existence of a project. If the
sponsor does not provide a charter, a good project management practice
is to create a Project Charter and insist that the project sponsor
approve it. After it is approved, the Project Charter, along with the
sponsor agreement, set the direction for the rest of the project's life
cycle. A Project Charter is a short, clear statement that includes the
following items:
In a matrix organizational structure, the project manager has more responsibility and authority than in the traditional functional organization. Formal line managers of personnel set the organization's mission and goals, authorize projects, and manage the personnel aspects.
Project managers are authorized and are responsible for running the organization's projects and for directing the work of the people assigned to their projects. Matrix organizations can make more efficient use of resources than traditional functional organizations, but they are more complex. The following key success factors apply to matrix organizations:
How Organizational Structures Influence Projects
Each organization finds the blend of functional and projectized organization structures to fit its needs. The blends that are closer to a traditional functional organization are called weak matrixed, and the blends that are more fully projectized are called strong matrixed. The following table illustrates how the levels of authority and responsibility differ between organizational structures. Note the following observations for this table, moving from left to right:
* The table is adapted fromA Guide to the Project Management Book of Knowledge , 2000 edition, (Newton Square, Penn: Project Management Institute, 2000), p 19.
Project Management System
The project management system (PM system) describes the way in which the project will be managed. The PM system is documented in a collection of individual plans, procedures, records, resources, and tools that are integrated to support project management activities. The graphic on the right side shows the parts of a PM system.
Project Management System Summary
Because the PM system is a collection of project documentation, it needs a central guide to describe how all the components fit together. The Project Management System Summary (PM System Summary) provides that overview and highlights the key points of the PM system. Think of the PM System Summary as an index or outline of your project's management system. The PM System Summary is a reference to help all team members understand how the project will be run. Every project should have a PM System Summary document. It is the project manager's responsibility to ensure that the project management system is documented, approved, implemented, and maintained. For small projects, it might be sufficient to document the entire PM system in a single PM System Summary. The PM System Summary is a typical starting point for project audits and compliance reviews.
The PM System Summary includes a brief description of each plan and procedure, and it indicates where the detailed plans, procedures, and records are filed. The PM System Summary and other project documents should be filed in the Project Control Book. The PM System Summary contains the following key sections:
Project Shaping Overview
The following tasks are important for understanding the business problem:
In my experience, one of the primary reasons that projects get into trouble is the failure to reach a common understanding of the requirements. Your interpretation of the requirements might not be the same as the client’s. And within the client’s organization, expectations are often different between the executives, MIS staff, and user groups. So exchanging requirements documents and responses between you and the client is not enough.
There is no substitute for an up-front walkthrough of the requirements. Invite your sponsor and other key stakeholders to a meeting to discuss what is in scope and what is excluded from the project. When specifying the deliverables, also be sure to identify the criteria for delivery to and acceptance by the sponsor.
Make the client understand it is to their advantage to go through this process early on to avoid costly misunderstandings later. After the contract has been signed, disagreements over requirements too often lead to client dissatisfaction, delays, and excess costs.
Estimating
As a project manager, you need a disciplined approach to develop estimates. A complete estimate incorporates the agreed-upon scope of work and all appropriate costs, but should also be revalidated throughout the life cycle of the project. The assumptions used to develop the estimate should be documented.
Anestimate
is an assessment of likely quantitative results. Estimates include
project labor cost, material costs, and hardware and software costs from other sources. Estimates are based on experience and
historical data from previous similar projects. Estimates should be
developed for the following reasons:
In contrast,cost budgeting
is allocating the cost estimate over the project's time span. This
time-phased cost budget (baseline) then becomes the plan-of-record
spending rate for financial performance measurement.
When to Perform an Estimate
Estimating is principally used during planning, after the Product Breakdown Structure (PBS) and Work Breakdown Structure (WBS) have been prepared. Estimates will be refined when work plans are expanded later in the project planning activities and will be revisited throughout the life cycle of the project. As more information is learned, the original assumptions, constraints, and basis for the estimate might change. On long-running projects, the Estimate to Complete (ETC) for the project is reassessed at regular intervals throughout the life cycle. An estimate might be modified for the following reasons:
What Should Be Estimated
In addition to costs, estimating involves determining the resources needed for the project. A resource is anything that might be used by the project, including human resources, facilities, and material. Other factors to be considered are effort and duration. The following list provides examples of factors included in an estimate:
The Estimating Process
Estimates are based upon information about the amount of effort, work unit duration, and the resource skills needed to accomplish the objectives of the project. These details are then used to update the Human Resource Plan and the Project Management Schedule. The major steps in the estimating process are shown below.
1. Establish estimating objectives: Clarify the objective of the estimate. To do this, the following questions should be asked:
Why is the estimate being prepared?
What is the required accuracy?
Who is the intended audience?
At what level of the Work Breakdown Structure (WBS) is the estimate to be done?
When is the estimate needed?
What are the desired outcomes?
Are there targets that have been set?
2. Determine project details: Identify the information needed to prepare the estimate. This includes task and project requirements and the proposed solution to the greatest level of detail available. The Project Charter, Project Definition, Product Breakdown Structure (PBS), Organizational Breakdown Structure (OBS), and WBS are all critical components. The accuracy of these documents determines the accuracy of the estimate. Understand how the sponsor's environment and your own environment might impact the estimate.
3. Develop an estimating strategy and plan: Define and document an initial set of assumptions and constraints that will be used to develop the estimate. You must also identify the estimators, develop a plan for gathering estimates, determine the estimation methods, and determine the type of validation to be used.
4. Select an appropriate estimating approach or method: The phase of the project life cycle, the method that is acceptable to the organization, and the project team's expertise in using a particular method should determine which method or approach to use. Consider using a top-down approach for high-level project estimates to decide whether to proceed with developing a proposal. Consider a bottom-up, task-by-task approach for a more detailed and accurate estimate. Estimating approaches include parametric estimating and function point estimating. It is also helpful to review the history of any similar projects to use as a basis for the estimate. Estimating methods are covered in the section "Guidelines and Methods for Estimating."
5. Prepare the estimate: Consider all available information that has been gathered in the preceding four steps. Be sure to include administrative support and project management effort. It is important that the project manager and all members of the estimating team fully document all assumptions, constraints, and risk items associated with the estimate. All of the components being acquired from external suppliers must also be identified.
Include contingencies associated with risk response planning. Recognize what is unique about this project and consider how this might affect the estimate. If you are working on an innovative project that no one has done before, or you are using unannounced products, your level of risk is higher and you should increase the contingency.
6. Validate the estimate: This step is important to ensure that the estimate is achievable. Get someone outside the estimating team to validate your methods and assumptions. The various ways to validate the estimate are:
Request an independent validation.
Perform a detailed analysis of every aspect of project plan and estimate.
Compare the estimate with actual results of similar projects.
Perform selected reviews in project plan areas where there is the most risk.
7. Document and baseline the estimate: Document the basis for the estimate, including assumptions, constraints, productivity levels, utilization factors, and cost factors. All members of the estimating team should document their portion of the estimate, and then have it reviewed and approved by the project manager. The project manager must be prepared to justify and defend the estimate by establishing sound assumptions and constraints, and by basing the estimate on facts and reality. The project manager must then present the estimate to management for approval and then the project is declared baselined.
8. Use the estimate in project plans: The baselined estimate is used to develop the price, the final project budget, and the financial plan. The pricing activity might require adjustments to the project schedule, such as smoothing the staffing curve to reduce cost or schedule duration.
Duration Based Estimating versus Effort Based Estimating
Estimates differ depending on whether a project is based on effort or duration. Know which is expected when you prepare estimates. For example, you would not want to prepare a duration-based estimate when the sponsor is expecting an effort-based estimate. Aspects of a project that are estimated include effort, project costs, and durations. Remember that the elapsed time to complete each work unit includes the work unit's duration plus any nonwork time, such as weekends, holidays, or vacations.
Duration-Based Estimating
Duration-based tasks assign resources to complete each task within a specified amount of elapsed time (for example, within a number of calendar days), no matter how much effort is required. Duration-based estimates require less estimating effort and might be on projects where utilization and labor hours are not measured.
Include the following factors when calculating duration:
Working time: Number of hours in a workday or workweek
Effort hours: Resource hours required to complete a task
Elapsed time: Calendar duration including weekends, holidays, and vacations
Productivity: The rate at which work is produced
Availability: Resources are present and ready to work
Level of effort: Activities necessary to support a project
Effort-Based Estimating
Effort-based estimates are needed for projects where utilization and labor hours are key project performance measures. Two formulas are used for calculating effort-based tasks: duration and cost.
The Duration Calculation formula is:
Duration =Effort/Productivity
Availability
Duration Based Estimating vs Effort Based Estimating
If you have a task that is estimated to take 120 hours and you are paying $10 per hour, and the resource is only available 75% of the time, and is only 80% productive, the duration calculation would be:
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))
The Cost Calculation formula is:
Cost = Effort X Unit Cost
Productivity
= 120 X $10 = 1200 = $1500
.80 .80
Note :
If you are paying people by the hour, then you are assuming they have
an availability of 100% because you pay them for the hours they work.
Therefore, there is no availability factor in the cost formula.
Example: Creating an Estimate
You are creating an estimate for your project. One of the project tasks is estimated to take 10 hours of effort at $100 per hour. The person performing this task is available 70% of the time over the duration of the project and has a productivity rate of 80%. The local mandate is one workday equals 8 hours. Using the duration and cost formulas provided earlier in this module:
How long will this task take to complete?
How much will this task cost?
Estimating Staff Resources
Staffing a project requires a great deal of analysis and consideration of a number of factors.
Estimating sufficient effort based upon the available staff competence and experience is essential for a successful project. When sharing resources across projects, the various project managers should agree to coordinate staff assignments to ensure that resources are not under-allocated or over-allocated.
When project managers estimate staff resources, the following fundamental questions might be helpful:
What level of competence is essential?
What effort is required?
What is the average length of a real workday? Utilization is typically reflected in tools by the number of hours in a workday.
Are there periods when each resource is not available? When
creating an estimate, project managers should determine the impact that
outages, such as planned vacation time, have on the project schedule and
estimates.
How long and what percentage of time will each person be allocated to the project? Is the person full-time or part-time?
Are there national mandated workweeks? In the United States,
it is 40 hours per week.
Note: 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. An FTE can be the combination of two or more individuals whose efforts equal one workday. In reality, personnel are not available full time, 8 hours per day, 40 hours per week, 52 weeks per year. Utilization rates consider the time required for education, vacation, holidays, administration, travel, and sick leave. Utilization is usually expressed as hours per day, but it can be expressed as a percentage of duration.
Estimating Methods
Estimates can be developed by using a number of methods. Different estimating methods are used at different times in the project life cycle, and they vary in accuracy. It is important to know the estimating method and the level of precision that is expected by your sponsor and management.
The following methods are the most common.
Top-down:
Top-down estimating yields high-level estimates of projects based on parametric estimates, analogy estimates, or expert judgment. This approach is based on collecting judgments and past experiences about previous similar activities. Top-down estimating is usually less costly, though, but it is also less accurate than other techniques. Top-down estimates are used most often early in the life cycle for proposals or for estimate activities in the distant future when little detailed information is known. A common problem with top-down estimates is that they can be greatly affected by the subjective, personal biases of the estimators.
The parametric estimate uses specific rates to estimate the effort required to complete a task or to produce a particular work product. Examples include number of lines of code per person-day, dollars per person per travel day, and number of person-days per function point. The parameters are usually categorized in terms of count (the number of items to be estimated), scaling factor (size and complexity), and fixed range (fixed amount or range for the estimate). The following guidelines apply to parametric estimates:
Every task must be measured by at least one parameter.
Parameters can, and typically do, apply to more than one task.
Any more than three parameters per task is unwieldy.
The analogy method, or comparison estimating method, uses the actual cost of a previous work unit or a previous project as the basis for estimating. The following steps are used in this method:
Evaluate the Product Breakdown Structure to identify the products and to organize the estimates.
Find comparable projects. If the attributes of the earlier project are not similar, the accuracy of the estimate will be significantly reduced.
Assess comparable project qualities to determine which factors can be used to estimate the current project. Consider how old the data is and whether the data is the actual costs or planned costs.
Evaluate the cost of the previous project.
Apply the information from the previous project to the estimate for the current project.
Expert judgment is an estimating method that relies on information provided by one or more experts with specialized knowledge and training. It is used to assess and adjust estimates to improve accuracy. An expert judgment estimate is only as good as the expert. Expert judgment can be used as part of any of the previous methods.
Bottom Up:
A bottom-up cost estimate involves receiving estimates for each work unit from the intended owners of the work units and then summarizing them in a project cost estimate. A good bottom-up estimate demonstrates a detailed understanding of the work to be done on a project. Bottom-up estimates are considered to be the most accurate but are usually costly. A common problem with bottom-up estimates is that the overall project estimate might be artificially inflated because each contributing work unit might add its own estimate contingency. It is important to ask the estimators what contingency they used in their estimate so that you do not add another contingency. Bottom-up estimates are used later in the project life cycle when more detailed data is available and the estimate must be more accurate.
The supplier estimating approach, also called bids, involves receiving estimates from all the suppliers on the project and then summarizing them in a cost estimate for the project. This is a form of bottom-up cost estimating. The disadvantage of this method is that the estimate could be inflated as suppliers add contingency to their estimates.
Estimate Types
Estimating for a project is done throughout the life of the project. The accuracy of estimates is expected to increase later in the life cycle when more information becomes available. The accuracy of an estimate is expressed as a plus or minus percentage range; for example, -5% / +10%. The following types of estimates are the three most common types:
The following table shows types of estimates, their accuracy, their use, and the estimating methods by type.
*See Jack R. Meredith and Samuel J. Mantel, Jr.,Project Management: A Managerial Approach , 3rd ed. (New York: John Wiley & Sons, Inc., 1995), pp. 291-293.
Validating an Estimate
Estimates should be thoroughly checked, or validated, to ensure that they are as accurate as possible.
TIPS:Base estimates on historical data and experience
When possible, base estimates on historical data and experience on similar projects. These estimates must be adjusted for differences between the projects.
TIPS: Review accuracy of team members’ past estimates
Determine whether the team members contributing to the estimate have a history of developing poor estimates. For example, if the software developer's estimates are usually low, then add a contingency to that estimate.
TIPS: Estimate a large number of small work units instead of a small number of large ones
In general, it is usually more accurate to estimate a large number of small work units instead of a small number of large ones. Estimating errors might cancel each other.
TIPS: Communicate the estimate's level of accuracy
Always communicate the estimate's level of accuracy. For example, a budgetary estimate has a -10% / +25% tolerance.
TIPS: Build two or more independent estimates
When time and cost allow, it might be helpful to build two or more independent estimates for the same set of activities and then to compare the results.
TIPS: Start with a simple and honest set of task estimates
Refine these estimates as more detail is known about the specific tasks being estimated.
TIPS: Add appropriate contingency
Consider level of project risk and add an appropriate contingency.
TIPS: Avoid starting with a presumed result and then working backward to fit the assumed estimate
If your estimates are not aligned with the target, you must resolve this to prevent setting false expectations.
TIPS: Build realistic and achievable estimates
Estimates must be realistic and achievable. Unrealistic estimates might win business, but they usually result in cost overruns. As the project manager, you will be held accountable for such overruns.
TIPS: Involve your project team in the estimating process
Involve your project team in the estimating process so that they can provide insight and will feel vested in the project.
TIPS: Use standards or standard costing
Use standards or standard costing, if they are available. Most locations have specific costs that apply to both materials and labor.
TIPS: Recognize that estimating takes time
Recognize that estimating takes time, and allocate sufficient time to develop the estimate. On average, it can take up to 2% of the total project schedule to develop an estimate.
TIPS: Document all assumptions and constraints
Document all assumptions and constraints. This is a critical step in the process: if the assumptions or constraints for the original estimate change, the estimate might not be valid. Sufficient documentation is key information for Quality Assurance reviews.
TIPS: Document the completed estimate
Document the completed estimate. Also, include the estimating approach.
TIPS: Validate the estimate
An estimate must be validated before it can be considered complete.
Why Are Estimates Important?
Estimates are important because they establish the basis for planning and establishing a baseline for tracking. I have found that many projects are doomed from the start because of poor estimating. A key to avoiding this is to invite experienced staff to validate the estimates and make adjustments for untested hardware and software, subcontractor underestimates, testing and correction periods, and the learning curve of using new tools and methods,
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 are not considered, the resulting estimate is invalid, and an invalid estimate leads to a difficult or, potentially, a failed project.
A schedule is a plan that is structured along a time dimension. A project management schedule is a road map of the duration and sequence of events and activities. In other words, it states what will be done, when it will be done, and who is responsible. It is composed of phases, activities, tasks, and milestones from the Work Breakdown Structure (WBS), along with resource information. A schedule also defines how the project interlocks with other projects. Typically, the schedules are created when the project during the Plan phase. After the schedule is approved, it is a key element of the project's baseline documentation.
Schedules are key management tools for tracking and communicating the progress of a project. As a project manager, you use project schedules for the following reasons:
A project management schedule can be represented in a variety of ways. In a bottom-up approach to creating a schedule, the three most common types of schedules used are the precedence network diagram, Gantt chart, and milestone chart as shown in the graphic.
Precedence Network Diagram
The precedence network diagram is the bridge that helps project managers create a Gantt chart from the Work Breakdown Structure (WBS). The precedence network diagram shows the WBS work units arranged in a logical work flow based upon their interdependencies. The most common format for a precedence network diagram shows work units as boxes or nodes and interdependency relationships as arrows.
By definition, a project has a specific start and finish. In the following graphic, notice that the precedence network diagram contains start and finish nodes. Start and finish nodes are required by scheduling tools, to properly calculate schedule dates. Also notice that the precedence network diagram is built only from the lower, more detailed levels in the WBS.
Precedence Network Diagram Relationships
A relationship in a precedence network diagram shows the sequence, or a logical work flow, of the work units. Within a single relationship in a precedence network diagram, the first work unit is called the predecessor and the second is called the successor. The three relationships commonly used in precedence network diagrams are described in the three buttons on this page:
Finish-to-Start
An FS relationship is the most common precedence relationship. The FS relationship means that the predecessor must finish before the successor can begin, such as in the following examples:
Finish-to-Finish
In an FF relationship, the predecessor activity must be completed before the successor activity can finish. FF relationships are used where there is a high degree of overlap between tasks, but one task cannot be completed without the other. FF relationships are typically used along with lag time to offset the predecessor from the successor. The following examples show FF relationships:
Start-to-Start
In an SS relationship, the predecessor activity must start before the successor activity can start. SS relationships are used where there is a high degree of overlap between tasks, but one task cannot be started without the other. SS relationships are typically used along with lag time to offset the predecessor and successor. The following examples show SS relationships:
Lead and Lag Time
Lead and lag times are used with FS, FF, and SS relationships to delay or accelerate the start of the successor task. Lag is usually represented by a positive number and lead is shown as a negative number. The following examples show this usage:
FS+1 means an FS relationship with a lag of one day. In other words, the successor will start one day after the predecessor has finished. An example for applying lag time in home construction is adding seven days of lag between pouring the concrete foundation and building the rest of the house (FS+7). This allows the concrete to harden before continuing with construction.
FS-1 means an FS relationship with a lead of one day. In other words, the successor will start one day before the predecessor has finished. An example of applying lead time in product development is overlapping software coding with writing the user guide. An FS-10 means the writers of the user guide will start 10 days before the software coding is finished.
Precedence Network Diagram Calculations
Creating a precedence network diagram includes calculating the start and end dates for each work unit. The start and end dates for most work units in a precedence network diagram can be adjusted without affecting the project's finish date. This is caused by float.
What is float?
Float is the amount of time that an activity can be delayed without delaying the finish date of the project. Project managers use float, or slack, to adjust work unit schedules to level resource allocations and accommodate schedule changes without impacting later milestone dates. There are two kinds of float:
Calculating the Start and Finish Dates
It is important to know how much each work unit can move without affecting the project's finish date. In other words, you need to know how early or how late each work work unit can be scheduled. This is represented with four dates, one in each corner of the work unit box:
These four dates are determined by performing a forward pass and a backward pass calculation on the precedence network diagram.
Forward Pass
The forward pass is used to calculate the early start (ES) and early finish (EF) dates for all the work units in a precedence network diagram. The forward pass begins from the Start milestone with the earliest date. For example, Task A begins on day one (ES = 1). Task A's duration of two days is added to the ES to calculate its early finish (EF = 3). One of Task A's successors is Task B. So Task B's early start (ES) equals Task A's early finish (EF). In the following graphic, work your way through each path of the precedence network diagram from left to right until all the work units are calculated. Notice how the type of relationship affects the calculation of the successor task:
Backward Pass
The backward pass is used to calculate the late start (LS) and late finish (LF) dates for all work units in a precedence network diagram. The backward pass is the reverse of the forward pass. A backward pass begins from the last work unit's EF, which was calculated in the forward pass. For example, Task F's EF is 21 and its duration of three days is subtracted to calculate its late start (LS=18). One of Task F's predecessors is Task G. So Task G's late finish (LF) equals Task F's late start (LS). In the following graphic, work your way backward through the precedence network diagram from right to left until all the work units are calculated. Notice how the type of relationship affects the calculation of the predecessor task:
Critical Path and Float Calculation
The critical path is the longest path in the precedence network diagram, so it determines the earliest finish (EF) of the project. The same example is used here to examine the critical path and float calculation. The critical path is highlighted in the diagram.
*See Jack R. Meredith and Samuel J. Mantel, Jr., Project Management: A Managerial Approach, 3rd ed. (New York: John Wiley & Sons, Inc., 1995), p. 347.
Precedence Network Diagram Completion
Before you translate the precedence network diagram into a Gantt chart, you should validate the following items:
Precedence Network Diagram Summary
The following steps summarize how to create a precedence network diagram:
Introduction to Project Management and Operational Schedules
A Gantt chart is a two-dimensional time-scaled graphical representation of the project's work units. The project manager uses information from many sources to create the Gantt schedule. Key sources are the structure hierarchy from the Work Breakdown Structure (WBS) and the logical sequence of work units from the precedence network diagram. The project manager then adds external dependencies, assigns task owners, and adjusts the duration, effort, and dates for each task.
The challenge is to coordinate all of these inputs into a schedule that satisfies the stakeholder's needs. Gantt schedules also contain milestones. Milestones have zero duration and are used to represent key events in the project.
Schedules for Large and Complex Projects
Large and complex projects might have so many tasks that it would be cumbersome to manage them all in one project management schedule. For such cases, project management schedules are built for each project organizational unit (POU), summarized to create the overall project management schedule, and then reconciled to ensure that the set of schedules is consistent.
The following graphics are examples of a project management schedule and operational schedules. Click each button for more information.
Project Management Schedule
A project management schedule defines the key milestone dates, the dependencies between the POU's operational schedules and all the work units that the overall project manager is responsible for accomplishing.
Operational Schedule
An operational schedule shows the work units to be accomplished by each
individual member of the subproject. An operational schedule is another type
of schedule that is often used when it is not appropriate to place an individual's
low-level details within the project management schedule.
An operational schedule has the following purposes:
Integrating Resources into the Schedule
Human Resource Plan -
The Human resource plan shows the number of people required to staff
the project, analyzed by skills and time. It is used to show how many
positions have been staffed and what positions are left to staff.
Logically Group Tasks -
Assign a logical group of tasks to each individual. For example,
assigning an individual all tasks needed to develop a software component
gives the person a sense of ownership for that deliverable.
Subproject Managers and Team Lead -
Add work units to account for subproject managers and team lead
efforts. A guideline is to have one full-time coordinator for every 6
to 12 professionals.
Non-project work - Allow for time spent on non-project work. A good guideline is 15 to 25%.
Resource Expertise
- Consider the expertise of the assigned resources. It might be
necessary to add training tasks or to lengthen task durations to allow
for a learning curve.
Non-available Time - Consider vacations, local holidays, and illness time. You will need to schedule around any non-available time.
Over-allocated Resources
- Look for over-allocated resources. Assuming over-utilization of
resources in the baseline plan will greatly increase the risk of project
failure. The graphic on the previous page illustrates how a resource
can be over-allocated during some period of a project. The project
manager should adjust the project management schedule task dates or
redistribute the tasks among other team members to balance the workload.
Hard-Coded Constraints
Most scheduling tools calculate task dates based upon a start as soon as possible (ASAP) default assumption. These tools also allow project managers to override the ASAP default with hard-coded date constraints on individual tasks. A date constraint might be useful for a milestone that must happen on a particular date. However, too many hard-coded date constraints can significantly affect the critical path and lengthen your project. Therefore, using hard-coded date constraints should be avoided unless there is a specific reason to use one. The following list describes some common hard-coded constraints:
Summary of Schedule Creation Steps
1. Review and understand key project documentation, including these examples:
• The project definition and the project organizational units (POUs)
• The Product Breakdown Structure (PBS) and the list of the work products
• The Work Breakdown Structure (WBS)
• The competencies of the available resources
• Any significant time and resource constraints
2. Copy the WBS and precedence network diagram information into a Gantt schedule format. Ensure that the WBS hierarchy structure and the precedence diagram work flow relationships are retained. The WBS hierarchy structure typically organizes work units into the levels of phases, activities, and tasks.
3. Divide the WBS work units into more detailed tasks, so that each task can be assigned to an individual to accomplish. The project manager must judge how much detail the schedule should contain. The project management Gantt schedules must be created in sufficient detail or divided into operational schedules so that the project team members, sponsors, and any subcontractors feel comfortable and can commit to their portion. A good guideline is to limit the length of tasks to between 40 to 80 hours.
For some projects, it might not be productive to prepare long-term detailed plans because they are likely to change significantly. A more effective technique might be to plan near-future tasks (typically the next three months) in detail, and plan long-term work at a higher level (at the activity or phase level).
As you progress through the project, you continually detail the near-future tasks that are just ahead. This is called the "rolling wave" scheduling technique. As the schedule detail expands, it is important that the baseline milestone dates remain unchanged.
4. Add detail to the work unit descriptions to clarify their completion criteria.
5. Sequence the work units by using linkages from the precedence network diagram. Where possible, linkages other than Finish-to-Start should be avoided.
6. Add any external dependencies. External dependencies are those work units outside the scope and control of the project but are required to complete the project; for example, the delivery of testing equipment from a third-party supplier.
7. Estimate the effort or duration required to complete each work unit.
8. Assign resources to each work unit.
9. For each resource determine the person's work week and any nonavailable time he or she might have.
10. Adjust task dates within the float to level peaks in resource allocations. Ensure that resources are not planned to work over 100% utilization.
11. Document any additional assumptions used in sequencing, estimating, and resource utilization. It might prove necessary to revise such assumptions and to update the schedule later in the project.
12. Continue to negotiate and adjust the schedule until you arrive at the best possible solution. Consider the following schedule adjustment techniques:
13. Compare the schedule to the agreement to ensure all requirements are satisfied. If all requirements cannot be satisfied, document any deviations for later review and approval of the sponsor. Update the work product list, as necessary.
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 these questions: Is this schedule based on reality? Can we really do it?
TIPS: Factor Resource Availability into the Schedule
On projects that do not carefully schedule skilled resources, I see the project managers spend a large amount of unplanned time to locate resources. Often, these resources cannot be quickly found or cost more than was planned. The best thing to do is to review the staffing plan with a resource manager, and be sure they are committed to providing key resources when needed.
Managing Risk
Risk management is an iterative process done throughout the life cycle of projects. It should be rigorously applied throughout the planning process so that it can deliver significant benefits in the Executing and Controlling phase. Risk management requires discipline and participation by project team members.
The Project Management Institute defines risk as, "An uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives."
Components of Risk
Risks are documented and analyzed in terms of the following three components:
What is Risk Management?
Risk management helps project managers to anticipate and avoid the negative consequences of risks. Risk management is a process that enables the project manager and project team to identify, assess, anticipate, and respond to risks throughout the life cycle of the project. Risk management is a continuous process that provides a disciplined environment for proactive decision making.
The risk management process is composed of five major steps:
The Project Manager's Role in Risk Management
The project manager is responsible for managing project risk. The project manager's role includes the following tasks:
The Risk Management Process
he following chart shows the steps to follow when performing risk management. Remember that risk management is an iterative process. You must go through this entire process regularly to ensure that new risks are identified and addressed. These steps are described in detail in this module.
These steps are performed iteratively throughout the execution of the project.
Risks are identified, analyzed, and managed at all levels within the project's Organizational Breakdown Structure (OBS). Risks at the top level tend to be global and deal with the overall project. Risks at lower levels in the OBS address the work to be performed at lower levels. For example, risks related to creating a project deliverable would be addressed by the project manager.
Risk Identification
Risk identification is considered the first step in the risk management process, and it is the first step in creating a Risk Management Plan. After situational factors for the project are analyzed, the risk identification step is used to locate risks. Information about the risks can then be incorporated into the risk management process. New risks can be identified at any time in the project. Risks should be identified early in the project, and then continuously identified throughout the life cycle.
Identified risks should be documented in the Risk Definition work product. The purpose of a Risk Definition is to provide the project stakeholders with complete and accurate information about the risks facing the project.
Using Inputs to Identify Risks
A variety of inputs can be searched to identify risks. The following list contains examples of other inputs:
Risk analysis is the second step in the risk management process, as shown in the following graphic. In this step, you define the probability and impact of each risk identified to determine the risk severity. Risks are then prioritized to determine what, if any, actions the project team is going to take for each. Risk analysis includes evaluating and prioritizing risks to determine the rank order in which the risks require attention.
Evaluating Risk
When evaluating a risk, estimate the probability of the risk occurring and the impact that it would cause if it occurred. Consider the following questions when estimating the probability, impact, time frame, and frequency of a risk:
Qualitative Analysis
A qualitative analysis is subjective, and it uses descriptive levels to estimate probability and impact. A typical set of descriptive levels uses low, medium, or high. Because low, medium, and high are relative terms, the project manager must ensure that key stakeholders are involved in defining each level's meaning and estimating each risk.
The probability of a risk occurring might be defined according to the following criteria:
Determining the Severity of the Risk
The severity of a risk event is determined by the combination of probability and impact. Risk severity can be used to prioritize or rank risks to help focus risk management efforts. It is important to remember that estimating risk impact and probability is typically a subjective effort based on expert judgment.
The following chart shows how the probability and impact can be used together to determine risk severity.
The following example of a risk table shows another method for determining risk severity. Notice that the last row shows a 25% probability versus a descriptive rating of high, medium, or low. Risk probability can also be expressed in values ranging from 0% (risk will not occur) to 100% (risk is certain to occur).
Prioritizing Risks
After the risks are analyzed, they must be prioritized so that the limited project resources can focus on the most severe risks. Comparing one risk to another risk achieves balance between project risks. For example, you might have to decide between losing $1 million on a $40 million project or coming in a month late. The project manager chooses the technique to be used on the project.
Filtering Technique for Prioritizing Risks
Filtering is a technique that prioritizes risks by asking a series of questions to filter out the following types of risks:
Comparative Risk Ranking for Prioritizing Risks
If the project team has difficulty prioritizing the risks, the comparative risk ranking (CRR) tool can be used to gain agreement. CRR is used to assess each risk against all the other risks to determine which is more severe. The project team votes on each pair of risks based on the defined selection criteria. The CRR technique can become cumbersome with more than five to six risks.
The filtering, ranking, and CRR techniques can work together. First, you can use a filtering process to determine the most severe risks, then use the ranking technique to prioritize the list, and then use CRR for the last few risks the team is having difficulty prioritizing.
Ranking Prioritized Risks
Prioritized risks come in different shapes and sizes; some prioritized risks have specific impacts. However, not all risks can be quantified. For most risks, a simple judgment of rank ordering the risks can be done with input from the project team members.
Risk Response Planning
The third step in the risk management process is risk response planning, as shown in the following graphic. Risk response planning involves deciding what, if anything, should be done to mitigate each risk. Risk response planning is performed throughout the project and at each level in the Organizational Breakdown Structure where risks are identified. Risk response planning includes incorporating the risk mitigation actions into the project plans.
Risk response planning includes the following tasks:
Be aware that risk response planning can introduce new risks to the project. For example, if a risk is transferred to a supplier because that supplier has greater skill and expertise, a new dependency risk has been created. Mitigation or contingency plans for one risk might also make current risks more tolerable. When developing your risk response strategy, consider the combination of risks, ability of the team to implement the strategy, and the project constraints.
Follow this approach to plan your strategies to mitigate risk:
Risk Response Options
Starting with the most severe risks, select the risk response options that will mitigate the risks with the lowest impact to the project.
Accept the Risk .
Accept the consequences of a risk occurring without further action, but
continue to observe for an increased likelihood of occurrence. If the
risk occurs, it will be handled as an issue. No further resources are
expended in managing the risk. Generally, these are risks that are not
significant or the risk response effort or cost is prohibitive.
Contain the Risk. The two types of risk containment are risk mitigation and risk contingency planning:
Transfer the Risk .
Transfer moves the risk accountability, responsibility, and authority
to outside the project's scope. Transfer implies acceptance of the risk
by another party using a tool, such as a contract or agreement. For
example, by using a fixed-price contract with a supplier, the risk of
cost overruns is transferred to the supplier. The project manager can
ask to be kept informed of the risk status so that the potential impact
on the project can be monitored. For each risk, determine if the risk
owner should be transferred to one of the following owners:
Use Insurance .
Cover the risk by an insurance arrangement. The cost of the insurance
policy must be included in the project's baseline cost.
Use Risk Reserve . The project manager decides to add some additional cost for the risk management reserve or risk contingency reserve.
A risk contingency reserve is held
inside a project's cost baseline and can be used to address future
situations that affect a project's costs or schedules. The risk
contingency reserve is controlled by the project manager.
Risk management reserves are not held for specific risks but
are held at a higher program or portfolio level. A risk management
reserve is held outside a project's cost baseline and can be used to
address future situations that affect a project's costs or schedules.
Establishing and using management reserves are generally controlled by
the delivery organization.
Risk Triggers
Risk triggers are predefined thresholds for project status measurement that identify when a risk is about to occur. Effective triggers provide an early risk event warning so that project personnel can quickly implement the risk response plan to minimize project impact. Triggers should be incorporated into the project status reported in the project's reoccurring status meetings.
Some examples of triggers include the following events:
Risk Management Plan
The Risk Management Plan includes the risk event description, mitigation, contingency, and reserve plans. In the following example of a Risk Management Plan, each row addresses a single risk with its rank, trigger, risk response plan, and owner of the response plan implementation. A single risk can have more than one planned response.
Make sure risk planning is made visible in the initial project review and to the sponsor, as appropriate. Only present risks to the sponsor if the sponsor needs to know or if the sponsor can affect the risk. Cost risks are not typically presented to the sponsor.
Risk Tracking and Control
Risk tracking and control is the fourth step in the risk management process, as shown in the following graphic. After the risks are analyzed, risk response options are assigned, and the Risk Management Plan is created, then the risks must be tracked. Data related to individual risks is collected, compiled, and analyzed to determine what, if any actions should be taken. Risk tracking depends on the availability of accurate, relevant, and timely risk-related data. More specifically, risk tracking and control rely on risk indicators and triggers, which are described in the section "Risk Triggers."
As part of risk tracking and control, perform the following activities:
Risk Reaction
Risk reaction is the fifth step in the risk management process, as indicated by the highlight on the React step of the graphic. Risk reaction includes executing risk responses and resolving risks as appropriate. A risk is resolved when it is no longer considered to be a significant threat to the project.
TIPS: The Importance of Risk Management
Before beginning a project, identify all major risks and your responses and contingency plans. When appropriate, have the client acknowledge the risks and agree to the responses. If the client disagrees with your approach, it is better to resolve the differences sooner rather than later.
Think about the triple constraints cost, schedule, and scope when you are identifying and analyzing risks. If one of the triple constraints changes due to a risk event, the other two elements are affected. Risk management helps you to reduce the impact of those risk events on each of the three constraints, helping to make your projects more successful.
The risk management plan enables you 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.
Finally, you don’t have to be the only person monitoring the risk triggers. Assign owners for each risk, ideally someone who is close to the work and can monitor the risk well ahead of it turning into a problem or issue. It is up to you to check that risk owners are performing their responsibilities as detailed in the risk management plan.
Completing the Project Plan
The completion of project plans is a significant milestone in the life cycle of a project. Completing the project plans includes defining requirements, shaping, estimating, and scheduling the project. At the end of the Planning Phase, the project manager commits to the completed plans, which will be used to measure actual project performance.
Considerations for Completing the Project Plan
This module focuses on the project plans and transaction documentation, such as a Statement of Work (SOW), the Document of Understanding (DOU), and the supporting project plans.
An agreement is a formal commitment between the project manager, the project manager's organization, and the project's sponsor. A documented and signed agreement is important project documentation. It provides a comprehensive definition of the commitments that the project must satisfy, plus the commitments of the sponsor and other key stakeholders. The structure and content of an agreement varies from project to project. Agreements with external sponsors usually require more detail and more scrutiny during reviews because they are legally binding contracts between the parties.
The agreement is referred to as the proposed agreement until both the delivery organization and the sponsor approve it. After the key issues are resolved, the agreement is approved. This approval authorizes the allocation of funds from the project sponsor and the assignment of resources from the delivery organization. The approval also freezes the agreement and supporting plans, which now form the project's baseline. The baseline is the criteria by which project performance is measured. If changes to the baseline are necessary, the change management process is used to update the agreement.
Approval of the key agreement typically happens after the planning or solution design phase. This time frame appears as a line after the Planning or Design phases in the following life cycle diagram. If the project is large or complex, each of the phases in the life cycle might be handled as a separate project within a program. If so, an agreement might be approved prior to each phase.
Project Phase Overview
Projects are divided into phases for tracking and control purposes. Phases are a collection of related activities needed to attain a major milestone.
Project phases typically conclude with a management, sponsor, or quality review of the accomplishments versus the committed plan. This reduces the overall project risk by ensuring that the project is on track at key milestones as it progresses through its life cycle. In large and complex endeavors, phases might be treated as separate projects.
Assessing and Validating Opportunities
Market Planning
Market planning activities can be grouped into three phases: Market Definition, Capability Assessment, and Investment Prioritization and Management.
- In the Market Definition phase, Marketing professionals collect data about customer needs and market characteristics from a variety of sources, such as customer focus groups, relationship management feedback, competitive information, and market analysis. That data is then used to divide the marketplace into specific market segments.
- In the Capability Assessment phase, the market segments are further studied.
- In the Investment Prioritization and Management phase, each business prioritizes the opportunities within its market segment to determine which opportunities to invest in.
Assessing and Selecting Opportunities Overview
Portfolio analysis uses a common assessment method to make investment decisions based upon customer buying behaviors. Portfolio analysis compares new business opportunities with current offerings and then chooses the most attractive opportunities to implement based upon profitability and alignment with the organization's strategy. Portfolio analysis might also deselect a current market segment and then discontinue or sell off the investment. There are two types of selection methods: numeric and nonnumeric.
- Numeric assessment involves two techniques: portfolio analysis and profitability measures. Portfolio analysis is also a way of identifying future and perceived opportunities. Profitability measures are used to compare the resource investment with the potential revenue of each opportunity. Examples of profitability measures include return on sales (ROS), return on investments (ROI), return on assets (ROA), and return on value (ROV).
- Nonnumeric assessment includes operating necessities, product extensions, and competitive necessities. An example of an operating necessity might be investing funds in a project to keep a critical operation going. Product extensions might be enhancing an existing product line with new versions. Competitive necessities might be updating a particular product to remain competitive with other products in a market segment.
Profitability measures are used to assess the financial return of various opportunities that help business decision makers. Project managers should be aware of which profitability measures are used to select their projects because these financial expectations tend to follow a project throughout its implementation. Common profitability measures include these examples:
- Return on sales (ROS)
- Return on assets (ROA)
- Return on investment (ROI)
- Gross profit
- Profit margin
- Pretax income (PTI)
- Present value (PV)
Know Project Selection Considerations
Some people use payback period when selecting projects: the quicker the payback, the better the project. However, this simplistic technique does not factor in the time value of money. So don’t use it. It is better to use a net present value or internal rate of return approach, which does factor in the time value of money.
Contract Basics
An agreement documents a plan to exchange services, solutions, and resources between parties. An agreement might be an external contract or an internal agreement:
- An external contract is a legally binding commitment between companies. External contracts are enforceable by law to protect the parties involved.
- An internal agreement is an agreement that establishes a formal relationship between the subsidiaries of the company.
The agreement defines each party's commitment to a project by establishing the rights and obligations of a buyer and a seller.
The agreement ensures that the completion criteria, pricing, and settlement of any future disputes are agreed to by both buyer and seller.
Terms and Conditions
The base terms and conditions establish the agreement framework within which the project is carried out, but they do not describe the deliverables of a particular project. Terms and conditions are usually defined in a base agreement that is already in place before a particular project starts. The management of the base agreement is usually outside the scope of the project manager's responsibilities, but it might be appropriate for the project manager to participate in negotiating the base terms and conditions.
Transaction Documentation
The transaction document formally defines the key aspects of a particular project's products or services. A typical transaction document is a Statement of Work (SOW). For large, external projects, it might be appropriate for experts to assist with the negotiations and for a senior manager from the delivery organization to lead the negotiations. When the parties belong to the same enterprise, the agreement is less formal. For example, a simple Document of Understanding (DOU) might be sufficient documentation. In either case, the agreement might include or refer to additional, more detailed documents, such as a specification for the solution.
A Statement of Work (SOW) is a binding statement of products and services that the seller provides to the buyer. Some of the items included in an SOW are key assumptions, buyer and seller responsibilities, schedules, project completion, and charges. Here is a sample of a Statement of Work.
Contract Management Roles
Project managers must be aware of the contractual relationships used in their projects. Most projects have just one sponsor and one or more suppliers. Internal suppliers should perform their contract obligations with the same rigor and discipline as external suppliers. The following graphic shows the contract roles of the sponsor, delivery organization, and the suppliers.
Contract Types and Risk
It is important to understand the differences between the common contract categories and types because each type has its own risks for the buyer and the seller.
Time-and-Materials (T&M): In a T&M, the buyer reimburses the seller for the labor and materials provided. The labor hourly rates and material price usually include the supplier's profit. A T&M contract is much like a CR contract. In a T&M contract, the supplier continues to bill the buyer, whether the project's objectives are met or not (except for unit price contracts). So the buyer takes the greater risk. Some common types of contracts within the Time-and-Materials category are Level-of-Effort (LOE), Unit Price, and Indefinite Delivery, Indefinite Quantity (IDIQ).
In a Level-of-Effort (LOE) contract, the seller provides a uniform level of activity over a specific period of time. In an LOE contract, the supplier continues to bill the buyer at a set amount of effort over the duration of the contract, whether the project's objectives are met or not. So the buyer takes the greater risk, but the amount of effort is capped at a set amount.
The Unit Price and Indefinite Delivery, Indefinite Quantity (IDIQ) contracts are like an FP contract. They commit to a fixed-unit price for high quantities of the product over a given period of time.
Contract Payment Options
There are different options for contract payment. Project managers need to be aware of how the payment options affect the project's revenue projection and financial management. The value of money tends to decrease over time, so the later the payment, the less it is worth. The Net Present Value (NPV) calculation is used to determine the value of payments in the future.
Factors in Choosing Contract Payment Option
Payment options are subject to all types of contract conditions. It is imperative for the project manager to understand these conditions and factor them into the decision-making process. The following factors affect contract payments:
- Level of confidence in the quality and stability of the reimbursements
- Level of confidence in the cost estimates
- Level of complexity of the project
- Marketplace and completion
- Size and amount of the contract
- Types and levels of risks and the seller's ability to manage them
- Types of clients or project sponsors, and the level of sophistication and experience in managing projects of a similar nature
Words and Phrases to Avoid in Agreements
Some words and phrases should be avoided when writing agreements. These words and phrases are either ambiguous or they imply a greater commitment than intended. Avoiding these words and phrases helps to reduce possible problems with the customer later in the project life cycle. The following examples are sensitive words and phrases to avoid in an agreement:
Words to avoid
all
guarantee
minimize
always
immediate
most (used as a superlative)
assure
instantaneous
never
best
insure
secure
ensure
largest
shall
every
least
warranty
exceed
maximize
will
fastest
meet
Suggested replacements for some of the words to be avoided
address increase should can many should not could may security-enhanced
designed to
most (used to indicate majority)
security-rich environment help reduce
Phrases to avoid
acceptable response time
error free
normal conditions
any number
etc.
sufficiently large sample
as necessary
fully guaranteed
time is of the essence
as required
highest quality
to your full satisfaction
best efforts
mutually satisfactory
without any problems
better than
Country-Specific Considerations
In addition to the general list of words shown, some country-specific situations are to be avoided in international engagements.
Request for Proposal
Preparing an RFP
Preparing a Proposal
After an RFP is received by the potential suppliers, they prepare a proposal to submit to the customer. The RFP process is a competition between suppliers to gain the customer's business. Each supplier submits a formal proposal with the most competitive solution to meet the customer's need. Although each proposal must be competitive, they must also be achievable. After the customer selects a supplier, the proposal becomes the basis of the contract.
While proposals are being written, a bidder's conference might be held. This is a meeting between the buyer and the potential bidders to make sure that all have an understanding of the work requirements. Sellers can ask questions about the work. The buyer documents all the questions, and then the answers are shared with all the potential sellers.
Evaluating the Proposal
After the proposal due date, the buyer assesses all the proposals that were submitted by the suppliers. The buyer uses several steps to evaluate and filter out unsuccessful proposals. First the proposals are checked to ensure that they meet the basic instructions in the RFP. Then, the remaining proposals are evaluated from a technical aspect and the supplier's ability to manage the proposal to a successful completion. The cost is evaluated against the value that each remaining proposal provides to the customer. The last step of the evaluation is to select the winning proposal and to notify the bidders who were not chosen.
TIPS: Set Your Client’s Expectations
It is important to begin managing client expectations early in the project. Because of the desire to win business, we may underestimate the complexity, costs, and time required for solutions. Therefore, you should include experienced staff in the early discussions with the client. Avoid the temptation to over promise and under deliver.
TIPS: Use the Contract Type Appropriate For the Work
I try to avoid fixed-price contracts, unless the project is short and relatively simple. Unless the scope of the project is defined in detail, the chances of a fixed-price contract completing on time and within budget are slim.
If possible, break down large projects into phases that are bid separately. Only give a firm price for the next phase of the project to be performed. For example, if there is no detailed design specification, use a time and materials contract on the requirements validation phase. Then you can offer a fixed price on the design phase.
Another concern of mine is whether the client has the resources, skills, infrastructure, and time to support the project. Before bidding a major project, I assess client readiness and develop an action plan with the client to address the concerns. If needed, add a post-implementation support task to keep the new solution running while the client’s staff is being trained to support it.
One last word of advice - Don’t ever work on a project without a contract!
Understanding Project Roles and Relationships
Because the authority of the project manager depends on the organizational structure, the project manager must understand and work within that structure. The project manager must be sure there is an approved Project Charter and that the project management system is documented in a Project Management System Summary. The project manager must identify all stakeholders and be aware of all project stakeholder perspectives. The project manager is responsible for blending these into a systematic approach that will achieve the goals of the project.
Project roles and relationships are often redefined as the project progresses through its life cycle. The previous graphic shows that roles and relationships must be understood throughout the project life cycle.
Successful Project Managers
The project manager identifies potential stakeholders early in the project and continuously checks for additional stakeholders throughout the project. Project stakeholders are those individuals and organizations who are involved in or might be affected by project activities. Stakeholders vary from project to project, but stakeholders usually include the project team, suppliers, delivery organization management, and the project sponsor.
The following graphic shows some of the stakeholders that a project manager might identify on a project, such as suppliers, management, and other business units.
The project sponsor is one of the most important stakeholders that the project manager should identify. The project sponsor plays an important role on the project. The sponsor must be committed to the project and have a personal stake in the project's success. A project sponsor might be internal or external such as a customer or a commissioning body. The sponsor is an individual who has the authority to perform the following responsibilities:
- Formally approve the agreement that authorizes work to begin
- Formally accept the project's deliverables
- Provide the funding needed to implement project activities
For the stakeholders, sponsor, the project team, and end-user representatives, the project manager is the single point of contact for communicating the project status and project decisions. The project manager plays multiple roles and must bring the project team members together and lead them toward successfully accomplishing the project's objectives. The project team might face many challenges, such as geographic separation and cultural differences. The project manager helps the team to overcome these hurdles. The project manager is ultimately responsible and accountable for the success of the project. On large projects, the project manager might delegate responsibilities to subproject managers and other team members.
The project manager role is demanding and requires a variety of technical, leadership, and management skills. Good "soft" skills are essential for a successful project manager. Project managers need a combination of management and leadership skills.
Successful Project Managers - Responsibilities
he responsibilities of a project manager are summarized in the following list:
- Participates in the project definition to ensure the project will be manageable
- Ensures that the triple constraints of requirements, schedule, and cost are understood and accepted by the stakeholders
- Verifies agreements and ensures that contract elements are understood and accepted by the stakeholders
- Initiates the project
- Forms the project team
- Leads the planning of the project's technical activities
- Sets up the project plans and processes that form the project management system (The project management system is described later in this module.)
- Tracks technical, progress, financial, and quality status, and identifies variances from the baseline
- Makes project plan adjustments when a variance occurs
- Assesses and manages the project's risks
- Resolves issues and problems that occur during the project
- Tracks suppliers' performance against established agreements
- Ensures sponsor and stakeholder satisfaction
- Plans for and communicates with all stakeholders as appropriate
- Tracks team member performance
- Ensures that the necessary infrastructure is in place for the team members to accomplish their tasks
- Uses a change control process to control scope
- Closes the project
Successful Project Managers - Soft Skills
Successful project managers exhibit the following behaviors:
- Builds and maintains project team morale
- Motivates and leads the project team
- Is able to juggle the many project activities and to prioritize team actions
- Coaches stakeholders through difficult times in the project
- Listens and communicates effectively
- Thinks systematically and plans ahead
- Provides critiques or praise, as appropriate
- Is detail oriented
- Assists team members in transitioning on the project and off the project
- Is committed to the project and pursues excellence
- Is aware of the organization's goals
- Is politically savvy
- Is cost conscious
- Is knowledgeable of business basics
- Is capable of understanding the needs of staff, customers, and management
- Is capable of coping with ambiguity, setbacks, and disappointments
- Is an effective negotiator
Project Charter
How do we know that a project officially exists?
A
- Business reasons for undertaking the project
- High-level objectives for the project
- Initial definition of roles and responsibilities, including the authority of the project manager
- Key stakeholders
- Boundaries and scope of the project
- Project constraints
- References to other, more detailed documents, such as a New Offering Request or a Request for Proposal
In a matrix organizational structure, the project manager has more responsibility and authority than in the traditional functional organization. Formal line managers of personnel set the organization's mission and goals, authorize projects, and manage the personnel aspects.
Project managers are authorized and are responsible for running the organization's projects and for directing the work of the people assigned to their projects. Matrix organizations can make more efficient use of resources than traditional functional organizations, but they are more complex. The following key success factors apply to matrix organizations:
- The split between the project manager's and the functional manager's authority and responsibility must be clearly defined.
- Good communication is needed between project managers and functional managers to ensure project team members are not giving conflicting directions.
How Organizational Structures Influence Projects
Each organization finds the blend of functional and projectized organization structures to fit its needs. The blends that are closer to a traditional functional organization are called weak matrixed, and the blends that are more fully projectized are called strong matrixed. The following table illustrates how the levels of authority and responsibility differ between organizational structures. Note the following observations for this table, moving from left to right:
- In a weak matrix, the project manager has less authority and might play more of a project coordinator role.
- In a strong matrix, or fully projectized organization, the project manager needs sufficient authority to successfully execute the project. A project manager cannot make the project commitments without the authority to make it happen. As the authority of the project manager increases, the percentage of project manager's time increases as well.
| Project Characteristics | Functional Organization | Matrix Organization | Projectized Organization | ||
|---|---|---|---|---|---|
| Weak | Strong | ||||
| Project manager's authority | Little or none | Limited | Moderate to high | High to almost total | |
| Percent of performing organization's personnel assigned full-time to project work | Virtually none | 0-25% | 50-90% | 85-100% | |
| Project manager's role | Part-time | Part-time | Full-time | Full-time | |
| Common titles for project manager's role | Project coordinator, project leader | Project coordinator, project leader | Project manager, program manager | Project manager, program manager | |
| Project management administrative staff | Part-time | Part-time | Full-time | Full-time | |
* The table is adapted from
Project Management System
The project management system (PM system) describes the way in which the project will be managed. The PM system is documented in a collection of individual plans, procedures, records, resources, and tools that are integrated to support project management activities. The graphic on the right side shows the parts of a PM system.
Project Management System Summary
Because the PM system is a collection of project documentation, it needs a central guide to describe how all the components fit together. The Project Management System Summary (PM System Summary) provides that overview and highlights the key points of the PM system. Think of the PM System Summary as an index or outline of your project's management system. The PM System Summary is a reference to help all team members understand how the project will be run. Every project should have a PM System Summary document. It is the project manager's responsibility to ensure that the project management system is documented, approved, implemented, and maintained. For small projects, it might be sufficient to document the entire PM system in a single PM System Summary. The PM System Summary is a typical starting point for project audits and compliance reviews.
The PM System Summary includes a brief description of each plan and procedure, and it indicates where the detailed plans, procedures, and records are filed. The PM System Summary and other project documents should be filed in the Project Control Book. The PM System Summary contains the following key sections:
- The Identification section identifies project or subproject names and managers.
- The Authorizations section includes delivery organization signatures, documents delegations, specifies project steering committee responsibilities, and indicates budget limitations and directions for project contingencies.
- The Roles section provides a brief description of the key stakeholders on the project.
- The Plans section provides information about the project deliverables and how the project will be managed. It also indicates where more detailed information about the plan can be located.
- The Procedures section specifies how key tasks will be performed and where more specific documentation about procedures is located.
- The Records section specifies which records will be maintained and where they will be located.
Design a Project Management System
To help the project team run smoothly,
it is important that you communicate the project management methodology
and tools that will be used on the project. One of the best tools to
use is the Project Control Book. It is where you store all the project
documentation, making it easy for team members to access information.
It is also where a quality assurance review team will start looking, so
keep it up to date.
Project Managers Are Not the Only Ones Responsible for Project Success
A project manager's story:
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
immediately 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.
Defining Requirements and Shaping Projects
By defining requirements and shaping a
project early in the project life cycle, you establish the foundation
for the later project phases to build upon. With a requirements document
that clearly defines the project scope and the Organizational Breakdown
Structure (OBS), Product Breakdown Structure (PBS), and Work Breakdown
Structure (WBS) tools to help you decompose the requirements into
manageable units of work, you build a path for project success.
Project Shaping Overview
Shaping the project starts with a
business problem. Business problems are the business challenges faced
by the project sponsor or a market segment that can be addressed by a
solution. The business problem might be articulated in a formal request
for a proposal, the result of a market segment needs analysis, or an
informal request from a customer.
The business problem is first translated into a project requirements document, which is a formally documented description of the sponsor's needs. The requirements and the information about the customer's organization are then analyzed to shape a solution. Key tools in this analysis are the Organizational Breakdown Structure (OBS), the Product Breakdown Structure (PBS), and the Work Breakdown Structure (WBS). The OBS, PBS, and WBS work products form the framework of the solution that is used to develop the project's baseline definition. Throughout this process, it is important to clearly identify and document what is included and what is excluded from consideration for the solution.
Understanding the Business Problem
Understanding the business problem is the first step when defining requirements, and it is crucial for setting the project in the right direction. The output of this step is a documented set of project requirements. These requirements form the foundation for the project to build upon. If the foundation is weak or off-center, the later phases of the project might fail.
The business problem is first translated into a project requirements document, which is a formally documented description of the sponsor's needs. The requirements and the information about the customer's organization are then analyzed to shape a solution. Key tools in this analysis are the Organizational Breakdown Structure (OBS), the Product Breakdown Structure (PBS), and the Work Breakdown Structure (WBS). The OBS, PBS, and WBS work products form the framework of the solution that is used to develop the project's baseline definition. Throughout this process, it is important to clearly identify and document what is included and what is excluded from consideration for the solution.
Understanding the Business Problem
Understanding the business problem is the first step when defining requirements, and it is crucial for setting the project in the right direction. The output of this step is a documented set of project requirements. These requirements form the foundation for the project to build upon. If the foundation is weak or off-center, the later phases of the project might fail.
The following tasks are important for understanding the business problem:
- Read all project documentation, such as the contract, Request for Proposal (RFP), Document of Understanding (DOU), Statement of Work (SOW), and other documents that might also contain requirements.
- Interview the sponsor to gain insight into the details behind the business need. Request to talk to future users and others that might be affected by the deliverables of the project. Then conduct another interview with the sponsor to follow up these discussions.
- Prioritize the business needs based on what the sponsor values and the delivery organization's capabilities.
- Document the requirements and validate your conclusions with the sponsor and key members of the delivery team.
- If the sponsor is asking for something that will not deliver the business benefit they are looking for, then explain that to them and persuade them to do something different.
Define the Requirements
Requirements define what the project will deliver. The requirements document is a formal, written 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.
1. Interviewing the Sponsor
The interview process identifies the customer stakeholders and asks a series of questions based on that person's role in the project. Start by interviewing the sponsor to get the sponsor's interpretation of the business needs that will be met by the project. The sponsor might also give you the names of other people to interview to gain more detailed insights. Explain to each interviewee what you are doing and the steps in the interview process, including gathering needs, categorizing them, and establishing the requirements document. The interview can be conducted in an informal manner or it can use structured requirements-gathering methods, such as brainstorming, nominal group technique, focus groups, workshops, and affinity diagrams.
In your interviews, ask the five basic questions: when, where, why, what, and how.
Sample Interview Questions
What is the benefit to you and your business of doing this project?
What is the impact to you and your business if this project is not undertaken?
What is your role in the business and the project?
What functionality and deliverable do you need?
Who are your stakeholders?
Who are the users of the deliverables?
What is the financial cost and benefit of this project for your organization?
Can the existing infrastructure support your needs?
What outside support is required?
How do you define success for this project?
What are your completion criteria?
When is the solution needed?
2. Getting from Needs to Requirements
The next step in the requirements-gathering process is to categorize the business needs into either requirements or exclusions. As you gather the needs, remember that the sponsor must approve the requirements document to proceed to the next step. Involving the sponsor early in the requirements-gathering process saves time and avoids problems.
All needs that are identified in the requirements-gathering step should be clearly documented. If possible, include pictures, graphics, models, and other exhibits. The needs that are not included in the requirements should be documented as exclusions so that the sponsor and other stakeholders can see that their input was recognized and that no information was lost. These exclusions might become requirements for a follow-on project. The following sample questions help to prioritize project needs as requirements or exclusions:
3. Analyzing and Validating Requirements
The documented requirements should be reviewed and approved by the project sponsor, stakeholders, and project team leads. Validation reviews help you understand if the documented requirements are really what the sponsor wanted and if the delivery organization can deliver the solution. Validation ensures that the key stakeholders agree with the requirements before you proceed to the next step in shaping the project.
The project team leads should be able to clearly answer or reasonably estimate the following questions about the requirements document:
4. Establishing the Requirements Baseline
The process of documenting and validating the requirements is an iterative process. Requirements usually go through several cycles before all stakeholders can agree on the final version. It is critical to obtain the sponsor's signature on the final requirements. After the project requirements are approved, the requirements are baselined and archived in the Project Control Book. Establishing a requirements baseline is one of the ways that project managers control the scope of a project and avoid scope creep. Controlling changes to the requirements baseline is one of the most important tasks of a project manager.
5. Pitfalls in Defining Requirements Baselines
The process of defining requirements can encounter many types of problems. Some problems with requirements definition and documentation are so subtle that they are not apparent until far into the project's life cycle. Poorly defined requirements are principal sources of cost and schedule overruns, and they can lead to project failure. The following list describes common problems to avoid when defining requirements:
*This list is based onJ. Davidson Frame, Managing Projects in Organizations: How to Make the Best Use of Time, Techniques, and People, rev. ed. (San Francisco: Jossey-Bass, 1995).
Decomposition Structures
Shaping a project requires an iterative and recursive process in which project details are identified, decomposed, and refined. The project might be shaped in multiple iterations. Portions of the project might be given to subteams to shape. The subprojects would be integrated and the project shaped again. Hierarchical structures are used to subdivide the project so that it can be organized into smaller, more manageable work units. Three hierarchical structures are commonly used to decompose and organize projects:
These breakdown structures can decompose the project into very small and granular elements. However, large, hierarchical structures with many elements can become cumbersome. It is recommended that these structures be used to understand just the higher-level organization of the project. The lower-level decomposition details can be completed later in the project Planning phase.
Breakdown Structures
Three hierarchical structures are commonly used to decompose and organize projects:
Organizational Breakdown Structure:
The Organizational Breakdown Structure (OBS) identifies the organizational structure, reporting responsibilities, and relative authority. The OBS is like the traditional organizational chart. However, the OBS depicts the relationship between the project, subproject, and suppliers. The OBS is useful when planning communications because it shows the reporting structures within the project.
The OBS is usually composed of three main components:
Product Breakdown Structure
The Product Breakdown Structure (PBS) is a hierarchical decomposition of the project's work products into the components that will be produced. The PBS starts with the deliverables defined in the Agreement and decomposes them into their contributing components. In other words, these are the components that must be integrated to build the customer deliverables.
The detail in the PBS depends upon how the components are likely to be sourced. More detail is provided about components to be built by the project team. Purchased components do not need to be decomposed into smaller parts.
The following questions should be asked when creating or updating a PBS:
Work Breakdown Structure
The Work Breakdown Structure (WBS) starts with the PBS and decomposes it into the work units needed to produce the project's deliverables. The WBS ensures that project requirements are defined. A work unit is a related set of activities that produce a verifiable output. Work units have start and end dates, defined effort, and precise completion criteria.
Often the termsphase , activity , and task
are used to describe descending levels of the WBS work units. These
levels are a way of decomposing the work effort into successively more
detailed work units to ensure that the full scope of the work is
understood. In general, the WBS should be developed to a level of
detail to show major work units.
Conceptually, there is one multilevel WBS for the whole project. In practice, the WBS might be developed in several separate structures. Within the whole project, each subproject might have a WBS that defines its activities in more detail; however, the integrity of the WBS for the entire project must be maintained.
TIPS: Get the Requirements Agreed to Before Developing a Solution
Requirements define what the project will deliver. The requirements document is a formal, written 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.
1. Interviewing the Sponsor
The interview process identifies the customer stakeholders and asks a series of questions based on that person's role in the project. Start by interviewing the sponsor to get the sponsor's interpretation of the business needs that will be met by the project. The sponsor might also give you the names of other people to interview to gain more detailed insights. Explain to each interviewee what you are doing and the steps in the interview process, including gathering needs, categorizing them, and establishing the requirements document. The interview can be conducted in an informal manner or it can use structured requirements-gathering methods, such as brainstorming, nominal group technique, focus groups, workshops, and affinity diagrams.
In your interviews, ask the five basic questions: when, where, why, what, and how.
Sample Interview Questions
2. Getting from Needs to Requirements
The next step in the requirements-gathering process is to categorize the business needs into either requirements or exclusions. As you gather the needs, remember that the sponsor must approve the requirements document to proceed to the next step. Involving the sponsor early in the requirements-gathering process saves time and avoids problems.
All needs that are identified in the requirements-gathering step should be clearly documented. If possible, include pictures, graphics, models, and other exhibits. The needs that are not included in the requirements should be documented as exclusions so that the sponsor and other stakeholders can see that their input was recognized and that no information was lost. These exclusions might become requirements for a follow-on project. The following sample questions help to prioritize project needs as requirements or exclusions:
- Is the need part of the sponsor's original intent?
- Can the need be satisfied by an existing solution, or will a new function or feature be needed?
- Will the cost of the need be within the sponsor's cost constraint?
- Can the need be delivered within the sponsor's time constraint?
- When compared with other needs in the solution, is it a logical fit?
- Is the need a realistic expectation considering the state of technology?
3. Analyzing and Validating Requirements
The documented requirements should be reviewed and approved by the project sponsor, stakeholders, and project team leads. Validation reviews help you understand if the documented requirements are really what the sponsor wanted and if the delivery organization can deliver the solution. Validation ensures that the key stakeholders agree with the requirements before you proceed to the next step in shaping the project.
The project team leads should be able to clearly answer or reasonably estimate the following questions about the requirements document:
- What should the product or service do?
- Who are the stakeholders?
- How much will it cost?
- What is the expense plan?
- How long is the development process?
- How will it be serviced and maintained?
- Can the existing infrastructure support it?
- What outside support is required?
- How will success be defined?
- What support system will keep it in place?
4. Establishing the Requirements Baseline
The process of documenting and validating the requirements is an iterative process. Requirements usually go through several cycles before all stakeholders can agree on the final version. It is critical to obtain the sponsor's signature on the final requirements. After the project requirements are approved, the requirements are baselined and archived in the Project Control Book. Establishing a requirements baseline is one of the ways that project managers control the scope of a project and avoid scope creep. Controlling changes to the requirements baseline is one of the most important tasks of a project manager.
5. Pitfalls in Defining Requirements Baselines
The process of defining requirements can encounter many types of problems. Some problems with requirements definition and documentation are so subtle that they are not apparent until far into the project's life cycle. Poorly defined requirements are principal sources of cost and schedule overruns, and they can lead to project failure. The following list describes common problems to avoid when defining requirements:
- Ambiguous or unclear requirements are the most common problem. Ensure that each requirement is documented in a way that will be objectively clear to the project manager and the sponsor when it has been satisfied.
- Requirements that require an undeveloped technology or invention carry a significant risk. It will not be clear if it can be satisfied until the project is far into the project's life cycle.
- Uncertainty about who will use the product could greatly affect the sponsor's user interface expectations.
- Overlapping, conflicting, and similar requirements can cause confusion later in the life cycle.
- Developers' values might distort the requirements. In addition, people analyzing the requirements might alter them so that they more closely reflect their own biases rather than the sponsor’s.*
*This list is based on
Decomposition Structures
Shaping a project requires an iterative and recursive process in which project details are identified, decomposed, and refined. The project might be shaped in multiple iterations. Portions of the project might be given to subteams to shape. The subprojects would be integrated and the project shaped again. Hierarchical structures are used to subdivide the project so that it can be organized into smaller, more manageable work units. Three hierarchical structures are commonly used to decompose and organize projects:
- The Organizational Breakdown Structure (OBS) decomposes organizations into individual human resources.
- The Product Breakdown Structure (PBS) decomposes the project scope into work products, deliverables, and components.
- The Work Breakdown Structure (WBS) decomposes the schedule work units into phases, activities, and tasks.
These breakdown structures can decompose the project into very small and granular elements. However, large, hierarchical structures with many elements can become cumbersome. It is recommended that these structures be used to understand just the higher-level organization of the project. The lower-level decomposition details can be completed later in the project Planning phase.
Breakdown Structures
Three hierarchical structures are commonly used to decompose and organize projects:
Organizational Breakdown Structure:
The Organizational Breakdown Structure (OBS) identifies the organizational structure, reporting responsibilities, and relative authority. The OBS is like the traditional organizational chart. However, the OBS depicts the relationship between the project, subproject, and suppliers. The OBS is useful when planning communications because it shows the reporting structures within the project.
The OBS is usually composed of three main components:
- The sponsor's organizational units
- The project team's organizational units
- The delivery organizational units, which might include the management team, project office, and support personnel
Product Breakdown Structure
The Product Breakdown Structure (PBS) is a hierarchical decomposition of the project's work products into the components that will be produced. The PBS starts with the deliverables defined in the Agreement and decomposes them into their contributing components. In other words, these are the components that must be integrated to build the customer deliverables.
The detail in the PBS depends upon how the components are likely to be sourced. More detail is provided about components to be built by the project team. Purchased components do not need to be decomposed into smaller parts.
The following questions should be asked when creating or updating a PBS:
- What are the components that must be produced, purchased, and integrated to build the deliverables?
- Is the lowest level of the PBS sufficient to aid in planning their creation?
- Which of the components should be purchased versus built?
- Does the project team have the skills to deliver the lower-level components?
Work Breakdown Structure
The Work Breakdown Structure (WBS) starts with the PBS and decomposes it into the work units needed to produce the project's deliverables. The WBS ensures that project requirements are defined. A work unit is a related set of activities that produce a verifiable output. Work units have start and end dates, defined effort, and precise completion criteria.
Often the terms
Conceptually, there is one multilevel WBS for the whole project. In practice, the WBS might be developed in several separate structures. Within the whole project, each subproject might have a WBS that defines its activities in more detail; however, the integrity of the WBS for the entire project must be maintained.
TIPS: Get the Requirements Agreed to Before Developing a Solution
In my experience, one of the primary reasons that projects get into trouble is the failure to reach a common understanding of the requirements. Your interpretation of the requirements might not be the same as the client’s. And within the client’s organization, expectations are often different between the executives, MIS staff, and user groups. So exchanging requirements documents and responses between you and the client is not enough.
There is no substitute for an up-front walkthrough of the requirements. Invite your sponsor and other key stakeholders to a meeting to discuss what is in scope and what is excluded from the project. When specifying the deliverables, also be sure to identify the criteria for delivery to and acceptance by the sponsor.
Make the client understand it is to their advantage to go through this process early on to avoid costly misunderstandings later. After the contract has been signed, disagreements over requirements too often lead to client dissatisfaction, delays, and excess costs.
Estimating
As a project manager, you need a disciplined approach to develop estimates. A complete estimate incorporates the agreed-upon scope of work and all appropriate costs, but should also be revalidated throughout the life cycle of the project. The assumptions used to develop the estimate should be documented.
An
- To determine the skill level, number of resources, and labor costs
- To serve as input to important decisions regarding proceeding or not proceeding with projects
- To establish a baseline estimate that serves as the basis for generating the project price and the project budget
- To establish a cost schedule against which to measure actual expenditures
In contrast,
When to Perform an Estimate
Estimating is principally used during planning, after the Product Breakdown Structure (PBS) and Work Breakdown Structure (WBS) have been prepared. Estimates will be refined when work plans are expanded later in the project planning activities and will be revisited throughout the life cycle of the project. As more information is learned, the original assumptions, constraints, and basis for the estimate might change. On long-running projects, the Estimate to Complete (ETC) for the project is reassessed at regular intervals throughout the life cycle. An estimate might be modified for the following reasons:
- The project is replanned, especially when moving from phase to phase.
- Change requests are submitted.
- The project's environment changes.
- Technologies evolve.
- The Work Breakdown Structure (WBS) has been developed or it has changed.
- A project manager has assumed responsibility for a new project and prepares an estimate or validates an existing estimate.
- Actuals differ from the latest estimate by more than a preset amount or percentage.
- An assumption changes
What Should Be Estimated
In addition to costs, estimating involves determining the resources needed for the project. A resource is anything that might be used by the project, including human resources, facilities, and material. Other factors to be considered are effort and duration. The following list provides examples of factors included in an estimate:
- Scope of tasks and work products
- Effort and duration
- Resources:
- Staff refers to the people assigned to the project. On some projects, resources are provided by the sponsor and should be accounted for in the project schedule. These resources might not be included in the cost of the project.
- Facilities include office space, information technology needs (IT), and technical environment.
- Material includes equipment, raw materials, and consumables.
- Cost:
- Cost is the funds a company spends to produce products or to
establish an infrastructure to provide services. Some examples of cost
include labor, raw materials, subcontractor labor, and third-party
hardware and software. There are several categories of cost:
- Direct cost is directly related to a work effort for a project. As the work effort increases, the direct costs increase at a similar rate. Project managers can usually exercise substantial control over direct costs. Direct costs are sometimes called variable costs.
- Indirect cost are shared among projects; for example, Quality Assurance, project office, and facility costs. Project managers usually have little control over indirect costs. Indirect costs are usually applied through an allocation process. Project managers need to understand the indirect expenses that apply to their projects. Indirect costs are sometimes called fixed costs.
- Cost is the funds a company spends to produce products or to
establish an infrastructure to provide services. Some examples of cost
include labor, raw materials, subcontractor labor, and third-party
hardware and software. There are several categories of cost:
- Expense:
- Selling, General, and Administrative (SG&A) expenses to support the operations and to sell services and products
- Expense for the overall management of the project
The Estimating Process
Estimates are based upon information about the amount of effort, work unit duration, and the resource skills needed to accomplish the objectives of the project. These details are then used to update the Human Resource Plan and the Project Management Schedule. The major steps in the estimating process are shown below.
1. Establish estimating objectives: Clarify the objective of the estimate. To do this, the following questions should be asked:
Why is the estimate being prepared?
What is the required accuracy?
Who is the intended audience?
At what level of the Work Breakdown Structure (WBS) is the estimate to be done?
When is the estimate needed?
What are the desired outcomes?
Are there targets that have been set?
2. Determine project details: Identify the information needed to prepare the estimate. This includes task and project requirements and the proposed solution to the greatest level of detail available. The Project Charter, Project Definition, Product Breakdown Structure (PBS), Organizational Breakdown Structure (OBS), and WBS are all critical components. The accuracy of these documents determines the accuracy of the estimate. Understand how the sponsor's environment and your own environment might impact the estimate.
3. Develop an estimating strategy and plan: Define and document an initial set of assumptions and constraints that will be used to develop the estimate. You must also identify the estimators, develop a plan for gathering estimates, determine the estimation methods, and determine the type of validation to be used.
4. Select an appropriate estimating approach or method: The phase of the project life cycle, the method that is acceptable to the organization, and the project team's expertise in using a particular method should determine which method or approach to use. Consider using a top-down approach for high-level project estimates to decide whether to proceed with developing a proposal. Consider a bottom-up, task-by-task approach for a more detailed and accurate estimate. Estimating approaches include parametric estimating and function point estimating. It is also helpful to review the history of any similar projects to use as a basis for the estimate. Estimating methods are covered in the section "Guidelines and Methods for Estimating."
5. Prepare the estimate: Consider all available information that has been gathered in the preceding four steps. Be sure to include administrative support and project management effort. It is important that the project manager and all members of the estimating team fully document all assumptions, constraints, and risk items associated with the estimate. All of the components being acquired from external suppliers must also be identified.
Include contingencies associated with risk response planning. Recognize what is unique about this project and consider how this might affect the estimate. If you are working on an innovative project that no one has done before, or you are using unannounced products, your level of risk is higher and you should increase the contingency.
6. Validate the estimate: This step is important to ensure that the estimate is achievable. Get someone outside the estimating team to validate your methods and assumptions. The various ways to validate the estimate are:
Request an independent validation.
Perform a detailed analysis of every aspect of project plan and estimate.
Compare the estimate with actual results of similar projects.
Perform selected reviews in project plan areas where there is the most risk.
7. Document and baseline the estimate: Document the basis for the estimate, including assumptions, constraints, productivity levels, utilization factors, and cost factors. All members of the estimating team should document their portion of the estimate, and then have it reviewed and approved by the project manager. The project manager must be prepared to justify and defend the estimate by establishing sound assumptions and constraints, and by basing the estimate on facts and reality. The project manager must then present the estimate to management for approval and then the project is declared baselined.
8. Use the estimate in project plans: The baselined estimate is used to develop the price, the final project budget, and the financial plan. The pricing activity might require adjustments to the project schedule, such as smoothing the staffing curve to reduce cost or schedule duration.
Duration Based Estimating versus Effort Based Estimating
Estimates differ depending on whether a project is based on effort or duration. Know which is expected when you prepare estimates. For example, you would not want to prepare a duration-based estimate when the sponsor is expecting an effort-based estimate. Aspects of a project that are estimated include effort, project costs, and durations. Remember that the elapsed time to complete each work unit includes the work unit's duration plus any nonwork time, such as weekends, holidays, or vacations.
Duration-Based Estimating
Duration-based tasks assign resources to complete each task within a specified amount of elapsed time (for example, within a number of calendar days), no matter how much effort is required. Duration-based estimates require less estimating effort and might be on projects where utilization and labor hours are not measured.
Include the following factors when calculating duration:
Working time: Number of hours in a workday or workweek
Effort hours: Resource hours required to complete a task
Elapsed time: Calendar duration including weekends, holidays, and vacations
Productivity: The rate at which work is produced
Availability: Resources are present and ready to work
Level of effort: Activities necessary to support a project
Effort-Based Estimating
Effort-based estimates are needed for projects where utilization and labor hours are key project performance measures. Two formulas are used for calculating effort-based tasks: duration and cost.
The Duration Calculation formula is:
Duration =
Availability
Duration Based Estimating vs Effort Based Estimating
If you have a task that is estimated to take 120 hours and you are paying $10 per hour, and the resource is only available 75% of the time, and is only 80% productive, the duration calculation would be:
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))
The Cost Calculation formula is:
Cost = Effort X Unit Cost
Productivity
= 120 X $10 = 1200 = $1500
.80 .80
Example: Creating an Estimate
You are creating an estimate for your project. One of the project tasks is estimated to take 10 hours of effort at $100 per hour. The person performing this task is available 70% of the time over the duration of the project and has a productivity rate of 80%. The local mandate is one workday equals 8 hours. Using the duration and cost formulas provided earlier in this module:
How long will this task take to complete?
How much will this task cost?
Estimating Staff Resources
Staffing a project requires a great deal of analysis and consideration of a number of factors.
Estimating sufficient effort based upon the available staff competence and experience is essential for a successful project. When sharing resources across projects, the various project managers should agree to coordinate staff assignments to ensure that resources are not under-allocated or over-allocated.
When project managers estimate staff resources, the following fundamental questions might be helpful:
Note: 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. An FTE can be the combination of two or more individuals whose efforts equal one workday. In reality, personnel are not available full time, 8 hours per day, 40 hours per week, 52 weeks per year. Utilization rates consider the time required for education, vacation, holidays, administration, travel, and sick leave. Utilization is usually expressed as hours per day, but it can be expressed as a percentage of duration.
Estimating Methods
Estimates can be developed by using a number of methods. Different estimating methods are used at different times in the project life cycle, and they vary in accuracy. It is important to know the estimating method and the level of precision that is expected by your sponsor and management.
The following methods are the most common.
Top-down:
Top-down estimating yields high-level estimates of projects based on parametric estimates, analogy estimates, or expert judgment. This approach is based on collecting judgments and past experiences about previous similar activities. Top-down estimating is usually less costly, though, but it is also less accurate than other techniques. Top-down estimates are used most often early in the life cycle for proposals or for estimate activities in the distant future when little detailed information is known. A common problem with top-down estimates is that they can be greatly affected by the subjective, personal biases of the estimators.
The parametric estimate uses specific rates to estimate the effort required to complete a task or to produce a particular work product. Examples include number of lines of code per person-day, dollars per person per travel day, and number of person-days per function point. The parameters are usually categorized in terms of count (the number of items to be estimated), scaling factor (size and complexity), and fixed range (fixed amount or range for the estimate). The following guidelines apply to parametric estimates:
Every task must be measured by at least one parameter.
Parameters can, and typically do, apply to more than one task.
Any more than three parameters per task is unwieldy.
The analogy method, or comparison estimating method, uses the actual cost of a previous work unit or a previous project as the basis for estimating. The following steps are used in this method:
Evaluate the Product Breakdown Structure to identify the products and to organize the estimates.
Find comparable projects. If the attributes of the earlier project are not similar, the accuracy of the estimate will be significantly reduced.
Assess comparable project qualities to determine which factors can be used to estimate the current project. Consider how old the data is and whether the data is the actual costs or planned costs.
Evaluate the cost of the previous project.
Apply the information from the previous project to the estimate for the current project.
Expert judgment is an estimating method that relies on information provided by one or more experts with specialized knowledge and training. It is used to assess and adjust estimates to improve accuracy. An expert judgment estimate is only as good as the expert. Expert judgment can be used as part of any of the previous methods.
Bottom Up:
A bottom-up cost estimate involves receiving estimates for each work unit from the intended owners of the work units and then summarizing them in a project cost estimate. A good bottom-up estimate demonstrates a detailed understanding of the work to be done on a project. Bottom-up estimates are considered to be the most accurate but are usually costly. A common problem with bottom-up estimates is that the overall project estimate might be artificially inflated because each contributing work unit might add its own estimate contingency. It is important to ask the estimators what contingency they used in their estimate so that you do not add another contingency. Bottom-up estimates are used later in the project life cycle when more detailed data is available and the estimate must be more accurate.
The supplier estimating approach, also called bids, involves receiving estimates from all the suppliers on the project and then summarizing them in a cost estimate for the project. This is a form of bottom-up cost estimating. The disadvantage of this method is that the estimate could be inflated as suppliers add contingency to their estimates.
Estimate Types
Estimating for a project is done throughout the life of the project. The accuracy of estimates is expected to increase later in the life cycle when more information becomes available. The accuracy of an estimate is expressed as a plus or minus percentage range; for example, -5% / +10%. The following types of estimates are the three most common types:
- The order of magnitude estimate is a top-down estimate. It is used during the early phases of a project for initial evaluation. It is also called a concept, preliminary, or feasibility estimate. Order of magnitude estimates provide an accuracy of -25% / +75%.
- The budgetary type of estimate is a more detailed analysis. It is a mixture of unit costs for labor, materials, and equipment. The budgetary estimate is developed from more detailed project data and is used later in the project planning phase. The budgetary estimates is also called the design, control, or appropriation estimate. Budgetary estimates provide an accuracy of -10% / +25%.
- The definitive type of estimate is a detailed, bottom-up estimate used for baseline proposals that will be committed to. It is prepared from well-defined data and specifications, and it is used prior to baselining the estimates. Definitive estimates provide an accuracy of -5% / +10%.
The following table shows types of estimates, their accuracy, their use, and the estimating methods by type.
| Type | Accuracy | Primary Use | Methods |
|---|---|---|---|
| Order of Magnitude | -25% / + 75% | Initial, Concept entry |
Analogy (Comparison) Parametric Expert judgment Top-down |
| Budgetary | -10% / +25% | Concept Decision Check Point (DCP), CRM - Request for Information (RFI), Preliminary response to a Request for Proposal (RFP) |
Analogy (Comparison) Parametric Expert judgment |
| Definitive | -5% / +10% | Plan DCP, CRM - Proposal |
Analogy (Comparison) Parametric Expert judgment Bottom-up |
*See Jack R. Meredith and Samuel J. Mantel, Jr.,
Validating an Estimate
Estimates should be thoroughly checked, or validated, to ensure that they are as accurate as possible.
TIPS:
When possible, base estimates on historical data and experience on similar projects. These estimates must be adjusted for differences between the projects.
Determine whether the team members contributing to the estimate have a history of developing poor estimates. For example, if the software developer's estimates are usually low, then add a contingency to that estimate.
In general, it is usually more accurate to estimate a large number of small work units instead of a small number of large ones. Estimating errors might cancel each other.
Always communicate the estimate's level of accuracy. For example, a budgetary estimate has a -10% / +25% tolerance.
When time and cost allow, it might be helpful to build two or more independent estimates for the same set of activities and then to compare the results.
Refine these estimates as more detail is known about the specific tasks being estimated.
Consider level of project risk and add an appropriate contingency.
If your estimates are not aligned with the target, you must resolve this to prevent setting false expectations.
Estimates must be realistic and achievable. Unrealistic estimates might win business, but they usually result in cost overruns. As the project manager, you will be held accountable for such overruns.
Involve your project team in the estimating process so that they can provide insight and will feel vested in the project.
Use standards or standard costing, if they are available. Most locations have specific costs that apply to both materials and labor.
Recognize that estimating takes time, and allocate sufficient time to develop the estimate. On average, it can take up to 2% of the total project schedule to develop an estimate.
Document all assumptions and constraints. This is a critical step in the process: if the assumptions or constraints for the original estimate change, the estimate might not be valid. Sufficient documentation is key information for Quality Assurance reviews.
Document the completed estimate. Also, include the estimating approach.
An estimate must be validated before it can be considered complete.
Why Are Estimates Important?
Estimates are important because they establish the basis for planning and establishing a baseline for tracking. I have found that many projects are doomed from the start because of poor estimating. A key to avoiding this is to invite experienced staff to validate the estimates and make adjustments for untested hardware and software, subcontractor underestimates, testing and correction periods, and the learning curve of using new tools and methods,
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 are not considered, the resulting estimate is invalid, and an invalid estimate leads to a difficult or, potentially, a failed project.
Scheduling
A realistic schedule forms the
basis for a successful project implementation. A well-planned project
management Gantt schedule, including a precedence network diagram with all
tasks linked into a logical work flow and the critical path highlighted, is the
first step to project success. You can use the project management Gantt
schedule to consolidate the Work Breakdown Structure (WBS) hierarchy,
precedence network diagram, and resource assignments into a single plan.
With a final validation and any necessary adjustments to the schedule, you are
ready to request sponsor approval and base-line the plan.
A schedule is a plan that is structured along a time dimension. A project management schedule is a road map of the duration and sequence of events and activities. In other words, it states what will be done, when it will be done, and who is responsible. It is composed of phases, activities, tasks, and milestones from the Work Breakdown Structure (WBS), along with resource information. A schedule also defines how the project interlocks with other projects. Typically, the schedules are created when the project during the Plan phase. After the schedule is approved, it is a key element of the project's baseline documentation.
Schedules are key management tools for tracking and communicating the progress of a project. As a project manager, you use project schedules for the following reasons:
- Tracking the planned versus actual progress
- Communicating project progress to your team, management, and sponsor
- Communicating project or subproject interdependencies to other project managers
- Determining the impact of a change request on resources and milestones
A project management schedule can be represented in a variety of ways. In a bottom-up approach to creating a schedule, the three most common types of schedules used are the precedence network diagram, Gantt chart, and milestone chart as shown in the graphic.
Precedence Network Diagram
The precedence network diagram is the bridge that helps project managers create a Gantt chart from the Work Breakdown Structure (WBS). The precedence network diagram shows the WBS work units arranged in a logical work flow based upon their interdependencies. The most common format for a precedence network diagram shows work units as boxes or nodes and interdependency relationships as arrows.
By definition, a project has a specific start and finish. In the following graphic, notice that the precedence network diagram contains start and finish nodes. Start and finish nodes are required by scheduling tools, to properly calculate schedule dates. Also notice that the precedence network diagram is built only from the lower, more detailed levels in the WBS.
Precedence Network Diagram Relationships
A relationship in a precedence network diagram shows the sequence, or a logical work flow, of the work units. Within a single relationship in a precedence network diagram, the first work unit is called the predecessor and the second is called the successor. The three relationships commonly used in precedence network diagrams are described in the three buttons on this page:
Finish-to-Start
An FS relationship is the most common precedence relationship. The FS relationship means that the predecessor must finish before the successor can begin, such as in the following examples:
- Pour the concrete; remove the frame.
- Define the requirements; write the code.
Finish-to-Finish
In an FF relationship, the predecessor activity must be completed before the successor activity can finish. FF relationships are used where there is a high degree of overlap between tasks, but one task cannot be completed without the other. FF relationships are typically used along with lag time to offset the predecessor from the successor. The following examples show FF relationships:
- Bake the turkey; bake the potatoes.
- Develop the product; develop the user guide.
Start-to-Start
In an SS relationship, the predecessor activity must start before the successor activity can start. SS relationships are used where there is a high degree of overlap between tasks, but one task cannot be started without the other. SS relationships are typically used along with lag time to offset the predecessor and successor. The following examples show SS relationships:
- Write chapter 1; edit book.
- Select a design; select vendors.
Lead and Lag Time
Lead and lag times are used with FS, FF, and SS relationships to delay or accelerate the start of the successor task. Lag is usually represented by a positive number and lead is shown as a negative number. The following examples show this usage:
FS+1 means an FS relationship with a lag of one day. In other words, the successor will start one day after the predecessor has finished. An example for applying lag time in home construction is adding seven days of lag between pouring the concrete foundation and building the rest of the house (FS+7). This allows the concrete to harden before continuing with construction.
FS-1 means an FS relationship with a lead of one day. In other words, the successor will start one day before the predecessor has finished. An example of applying lead time in product development is overlapping software coding with writing the user guide. An FS-10 means the writers of the user guide will start 10 days before the software coding is finished.
Precedence Network Diagram Calculations
Creating a precedence network diagram includes calculating the start and end dates for each work unit. The start and end dates for most work units in a precedence network diagram can be adjusted without affecting the project's finish date. This is caused by float.
What is float?
Float is the amount of time that an activity can be delayed without delaying the finish date of the project. Project managers use float, or slack, to adjust work unit schedules to level resource allocations and accommodate schedule changes without impacting later milestone dates. There are two kinds of float:
- Free float is the amount of time a single activity can be delayed without delaying its successor.
- Total float, float, or slack is the amount of time an activity can be delayed without delaying the finish date of the project.
Calculating the Start and Finish Dates
It is important to know how much each work unit can move without affecting the project's finish date. In other words, you need to know how early or how late each work work unit can be scheduled. This is represented with four dates, one in each corner of the work unit box:
- An early start (ES) is the earliest possible time an activity can start.
- A late start (LS) is the latest possible time a work unit can start without delaying the project's finish date.
- An early finish (EF) is the earliest possible time at which a work unit can be finished.
- A late finish (LF) is the latest possible time a work unit can be finished without delaying the project's finish date.
These four dates are determined by performing a forward pass and a backward pass calculation on the precedence network diagram.
Forward Pass
The forward pass is used to calculate the early start (ES) and early finish (EF) dates for all the work units in a precedence network diagram. The forward pass begins from the Start milestone with the earliest date. For example, Task A begins on day one (ES = 1). Task A's duration of two days is added to the ES to calculate its early finish (EF = 3). One of Task A's successors is Task B. So Task B's early start (ES) equals Task A's early finish (EF). In the following graphic, work your way through each path of the precedence network diagram from left to right until all the work units are calculated. Notice how the type of relationship affects the calculation of the successor task:
- In an FS relationship, the predecessor task's EF = the successor task's ES.
- In an SS relationship, the predecessor task's ES = the successor task's ES.
Backward Pass
The backward pass is used to calculate the late start (LS) and late finish (LF) dates for all work units in a precedence network diagram. The backward pass is the reverse of the forward pass. A backward pass begins from the last work unit's EF, which was calculated in the forward pass. For example, Task F's EF is 21 and its duration of three days is subtracted to calculate its late start (LS=18). One of Task F's predecessors is Task G. So Task G's late finish (LF) equals Task F's late start (LS). In the following graphic, work your way backward through the precedence network diagram from right to left until all the work units are calculated. Notice how the type of relationship affects the calculation of the predecessor task:
- In an FS relationship, the successor task's LS = the predecessor task's LF.
Critical Path and Float Calculation
The critical path is the longest path in the precedence network diagram, so it determines the earliest finish (EF) of the project. The same example is used here to examine the critical path and float calculation. The critical path is highlighted in the diagram.
- For the tasks not on the critical path, their ES and LS are different and their EF and LF are different. The difference between the ES and LS indicates the task's total float. For example, Task G has three days of total float (LS minus ES). So, Task G could start anywhere between day 3 and day 6 without impacting the project's finish date (Task F).
- For the tasks on the critical path, the ES = LS and the EF = LF. This indicates there is no float. Any change to these tasks will affect the project's finish date (Task F). Project managers must closely manage critical path work units to ensure that projects achieve a baseline schedule. A project might have multiple critical paths. This significantly increases the risk of missing the project's finish date because there is more than one path that cannot slip.
*See Jack R. Meredith and Samuel J. Mantel, Jr., Project Management: A Managerial Approach, 3rd ed. (New York: John Wiley & Sons, Inc., 1995), p. 347.
Precedence Network Diagram Completion
Before you translate the precedence network diagram into a Gantt chart, you should validate the following items:
- Ensure that your network is complete and current:
- The project network diagram has one start and one finish milestone.
- The critical path is correctly identified.
- Check for danglers, which are work units that are missing either a predecessor or a successor. Only the start and finish milestones do not have predecessors and successors.
- Check for loops. Circular relationships do not allow an end date to be defined. Most scheduling tools do not allow loops.
- Try to avoid having more than one critical path. The critical path is a path with zero float. The network might have several paths with very low float. It is important that those paths be watched because they can quickly become another critical path.
- Ensure that the project's objectives can be met.
- Do milestones need to be added?
- Which tasks have external dependencies?
- Has all work for the project's deliverables been included?
- Can the deliverables be completed in the desired time frame?
Precedence Network Diagram Summary
The following steps summarize how to create a precedence network diagram:
- Establish a start milestone.
- Identify the first work units of the project's work flow.
- From left to right, add the work units in a logical sequence and link them with the appropriate FS, FF, or SS relationship.
- Ensure that there are no danglers.
- Calculate the forward pass, and determine the early finish (EF) of the project's completion milestone.
- Calculate the backward pass.
- Calculate the float.
- Identify the critical path and near-critical paths.
- Validate the network to ensure that it is correct and complete and that it achieves the project's objectives.
- As the project progresses and changes occur, the precedence network diagram should be updated.
Introduction to Project Management and Operational Schedules
A Gantt chart is a two-dimensional time-scaled graphical representation of the project's work units. The project manager uses information from many sources to create the Gantt schedule. Key sources are the structure hierarchy from the Work Breakdown Structure (WBS) and the logical sequence of work units from the precedence network diagram. The project manager then adds external dependencies, assigns task owners, and adjusts the duration, effort, and dates for each task.
The challenge is to coordinate all of these inputs into a schedule that satisfies the stakeholder's needs. Gantt schedules also contain milestones. Milestones have zero duration and are used to represent key events in the project.
Schedules for Large and Complex Projects
Large and complex projects might have so many tasks that it would be cumbersome to manage them all in one project management schedule. For such cases, project management schedules are built for each project organizational unit (POU), summarized to create the overall project management schedule, and then reconciled to ensure that the set of schedules is consistent.
The following graphics are examples of a project management schedule and operational schedules. Click each button for more information.
Project Management Schedule
A project management schedule defines the key milestone dates, the dependencies between the POU's operational schedules and all the work units that the overall project manager is responsible for accomplishing.
Operational Schedule
An operational schedule shows the work units to be accomplished by each
individual member of the subproject. An operational schedule is another type
of schedule that is often used when it is not appropriate to place an individual's
low-level details within the project management schedule.
An operational schedule has the following purposes:
- Divides the project management schedule into subsets that are easier for the subproject teams to work with
- Provides members of the project team with a list of work items to achieve within a period of time and the planned effort that determines how to organize and perform their work
- Enables the team leaders to track the progress (percent complete) of team members on their work items
Integrating Resources into the Schedule
Many variables must be considered when adding resources to a project management schedule.
For example, during the Project Planning phase, first
determine what must be done to complete each task and then identify the
necessary skills. Then during the Starting phase, find individuals who
are available and who have the required skills, and assign them to the
tasks.
TIPS: It is important not to baseline your schedule until you have examined and resolved your resource issues.
Appropriately Assigned Resources - Ensure that all work units have the appropriate skilled resource assigned to them. During the Planning phase, it is typical to assign generic resource types based upon the needed competency or skill level.
To complete the project management schedule, you must replace the resource type with assigned individuals.
Hard-Coded Constraints
Most scheduling tools calculate task dates based upon a start as soon as possible (ASAP) default assumption. These tools also allow project managers to override the ASAP default with hard-coded date constraints on individual tasks. A date constraint might be useful for a milestone that must happen on a particular date. However, too many hard-coded date constraints can significantly affect the critical path and lengthen your project. Therefore, using hard-coded date constraints should be avoided unless there is a specific reason to use one. The following list describes some common hard-coded constraints:
Summary of Schedule Creation Steps
1. Review and understand key project documentation, including these examples:
• The project definition and the project organizational units (POUs)
• The Product Breakdown Structure (PBS) and the list of the work products
• The Work Breakdown Structure (WBS)
• The competencies of the available resources
• Any significant time and resource constraints
2. Copy the WBS and precedence network diagram information into a Gantt schedule format. Ensure that the WBS hierarchy structure and the precedence diagram work flow relationships are retained. The WBS hierarchy structure typically organizes work units into the levels of phases, activities, and tasks.
3. Divide the WBS work units into more detailed tasks, so that each task can be assigned to an individual to accomplish. The project manager must judge how much detail the schedule should contain. The project management Gantt schedules must be created in sufficient detail or divided into operational schedules so that the project team members, sponsors, and any subcontractors feel comfortable and can commit to their portion. A good guideline is to limit the length of tasks to between 40 to 80 hours.
For some projects, it might not be productive to prepare long-term detailed plans because they are likely to change significantly. A more effective technique might be to plan near-future tasks (typically the next three months) in detail, and plan long-term work at a higher level (at the activity or phase level).
As you progress through the project, you continually detail the near-future tasks that are just ahead. This is called the "rolling wave" scheduling technique. As the schedule detail expands, it is important that the baseline milestone dates remain unchanged.
4. Add detail to the work unit descriptions to clarify their completion criteria.
5. Sequence the work units by using linkages from the precedence network diagram. Where possible, linkages other than Finish-to-Start should be avoided.
6. Add any external dependencies. External dependencies are those work units outside the scope and control of the project but are required to complete the project; for example, the delivery of testing equipment from a third-party supplier.
7. Estimate the effort or duration required to complete each work unit.
8. Assign resources to each work unit.
9. For each resource determine the person's work week and any nonavailable time he or she might have.
10. Adjust task dates within the float to level peaks in resource allocations. Ensure that resources are not planned to work over 100% utilization.
11. Document any additional assumptions used in sequencing, estimating, and resource utilization. It might prove necessary to revise such assumptions and to update the schedule later in the project.
12. Continue to negotiate and adjust the schedule until you arrive at the best possible solution. Consider the following schedule adjustment techniques:
- Crash or fast-track the schedule. This means compressing the project schedule by overlapping activities or adding resources. This technique usually increases project cost and risk.
- Change the approach. Changing your approach to the work might reduce effort and shorten the critical path.
- Reevaluate external dependencies. Determine if any finish-to-start relationships can be changed to finish-to-finish relationships.
- Revisit any constraints. Determine if any constraints on the critical path might start or end sooner.
- Use float. Consider using the float you have available to adjust the schedule.
13. Compare the schedule to the agreement to ensure all requirements are satisfied. If all requirements cannot be satisfied, document any deviations for later review and approval of the sponsor. Update the work product list, as necessary.
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 these questions: Is this schedule based on reality? Can we really do it?
TIPS: Factor Resource Availability into the Schedule
On projects that do not carefully schedule skilled resources, I see the project managers spend a large amount of unplanned time to locate resources. Often, these resources cannot be quickly found or cost more than was planned. The best thing to do is to review the staffing plan with a resource manager, and be sure they are committed to providing key resources when needed.
Managing Risk
Risk management is an iterative process done throughout the life cycle of projects. It should be rigorously applied throughout the planning process so that it can deliver significant benefits in the Executing and Controlling phase. Risk management requires discipline and participation by project team members.
The Project Management Institute defines risk as, "An uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives."
Components of Risk
Risks are documented and analyzed in terms of the following three components:
- Risk Event: Is a description of a project risk that includes a timeframe for occurrence -- milestone or project phase.
- Probability: Is a judgment about how likely the event is to happen.
- Impact: Is the amount of effect that the event would have on the project cost, schedule, quality, or customer satisfaction.
- Risks of driving to work
Event: You are in an automobile accident.
Probability: The probability varies depending on your driving ability, the amount of traffic, the time of day, weather conditions, and other factors.
Impact: The impact of the accident could include a loss of life, health, money, or time.
- Risks of working on the computer
Event: The computer hard disk drive crashes.
Probability: The probability varies, depending mostly on the quality, age, and condition of the computer.
Impact: The impact of the hard disk drive crash is the cost of the hard disk drive, lost data, and loss of time.
What is Risk Management?
Risk management helps project managers to anticipate and avoid the negative consequences of risks. Risk management is a process that enables the project manager and project team to identify, assess, anticipate, and respond to risks throughout the life cycle of the project. Risk management is a continuous process that provides a disciplined environment for proactive decision making.
The risk management process is composed of five major steps:
- Identify
- Analyze
- Plan
- Track
- React
The Project Manager's Role in Risk Management
The project manager is responsible for managing project risk. The project manager's role includes the following tasks:
- Facilitating the risk management process as a continuous process throughout the project
- Identifying, understanding, and prioritizing risks based upon their impact
- Planning mitigation actions for the most significant risks
- Documenting the Risk Management Plan as part of the project management system
- Monitoring the project for risk occurrences and to communicate risk status on a regular basis
- Periodically reassessing risk
- Calling for independent reviews when needed
The Risk Management Process
he following chart shows the steps to follow when performing risk management. Remember that risk management is an iterative process. You must go through this entire process regularly to ensure that new risks are identified and addressed. These steps are described in detail in this module.
These steps are performed iteratively throughout the execution of the project.
Risks are identified, analyzed, and managed at all levels within the project's Organizational Breakdown Structure (OBS). Risks at the top level tend to be global and deal with the overall project. Risks at lower levels in the OBS address the work to be performed at lower levels. For example, risks related to creating a project deliverable would be addressed by the project manager.
Risk Identification
Risk identification is considered the first step in the risk management process, and it is the first step in creating a Risk Management Plan. After situational factors for the project are analyzed, the risk identification step is used to locate risks. Information about the risks can then be incorporated into the risk management process. New risks can be identified at any time in the project. Risks should be identified early in the project, and then continuously identified throughout the life cycle.
Identified risks should be documented in the Risk Definition work product. The purpose of a Risk Definition is to provide the project stakeholders with complete and accurate information about the risks facing the project.
Using Inputs to Identify Risks
A variety of inputs can be searched to identify risks. The following list contains examples of other inputs:
- Contractual requirements
- Statement of Work
- Work Breakdown Structure (Look at each work product and consider what can go wrong.)
- Supplier contracts and customer agreements
- Field and marketing information
- Project plan assumptions
- Offerings portfolio
- Lessons-learned files and previous projects
- Other project-related plans
- Schedule
- Review reports
- Project plan dependencies
- Resource sourcing
- Stakeholder feedback
Risk analysis is the second step in the risk management process, as shown in the following graphic. In this step, you define the probability and impact of each risk identified to determine the risk severity. Risks are then prioritized to determine what, if any, actions the project team is going to take for each. Risk analysis includes evaluating and prioritizing risks to determine the rank order in which the risks require attention.
Evaluating Risk
When evaluating a risk, estimate the probability of the risk occurring and the impact that it would cause if it occurred. Consider the following questions when estimating the probability, impact, time frame, and frequency of a risk:
Qualitative Analysis
A qualitative analysis is subjective, and it uses descriptive levels to estimate probability and impact. A typical set of descriptive levels uses low, medium, or high. Because low, medium, and high are relative terms, the project manager must ensure that key stakeholders are involved in defining each level's meaning and estimating each risk.
The probability of a risk occurring might be defined according to the following criteria:
- Low probability: The event has little chance of occurring.
- Medium probability: The event has some chance of occurring.
- High probability: The event is likely to occur.
- Financial loss: Impacts to project costs resulting from budget overruns or penalties
- Time loss: Impacts to project schedule
- Quality loss: Impacts to acceptance criteria
- Functionality loss: Impacts to some property that the delivered solution should possess
- Resource loss: Impacts to staff, skills, equipment, and so on
- Sponsor satisfaction loss: Impacts to measured sponsor satisfaction
- Low impact: The event has little potential to disrupt the project.
- Medium impact: The event has some potential to disrupt the project.
- High impact: The event is likely to seriously disrupt the project.
Determining the Severity of the Risk
The severity of a risk event is determined by the combination of probability and impact. Risk severity can be used to prioritize or rank risks to help focus risk management efforts. It is important to remember that estimating risk impact and probability is typically a subjective effort based on expert judgment.
The following chart shows how the probability and impact can be used together to determine risk severity.
The following example of a risk table shows another method for determining risk severity. Notice that the last row shows a 25% probability versus a descriptive rating of high, medium, or low. Risk probability can also be expressed in values ranging from 0% (risk will not occur) to 100% (risk is certain to occur).
| Risks | Probability | Impact | Risk Severity |
|---|---|---|---|
| Incomplete user centered design analysis leads to training and product use problems after delivery. | Low | Moderate | Significant |
| Insufficient time to perform product verification test leads to errors found post-delivery. | High | Very high; users reject the system; 2 months to perform the test. | Major |
| Elements not fully integrated into operating system public build lead to system test failures and delays in product release. | Low | Very low; $5,000 and a 1-week delay to time-to-market. | Minor |
| No test suites available for required open system standards prevent product acceptance or integration with other equipment. | Moderate | Moderate: 6-week delay in verification. | Significant |
| Use of new IPD methodology will delay delivery schedule. | 25% probability (based on past projects) | $20,000 for training; add 2 weeks to schedule. | Low |
Prioritizing Risks
After the risks are analyzed, they must be prioritized so that the limited project resources can focus on the most severe risks. Comparing one risk to another risk achieves balance between project risks. For example, you might have to decide between losing $1 million on a $40 million project or coming in a month late. The project manager chooses the technique to be used on the project.
Filtering Technique for Prioritizing Risks
Filtering is a technique that prioritizes risks by asking a series of questions to filter out the following types of risks:
- Does the risk have significant impact?
- Is the risk likely to happen?
- Is the risk likely to happen in the immediate future, and does it require immediate mitigation action planning?
- Is the risk within the control or influence of the project?
Comparative Risk Ranking for Prioritizing Risks
If the project team has difficulty prioritizing the risks, the comparative risk ranking (CRR) tool can be used to gain agreement. CRR is used to assess each risk against all the other risks to determine which is more severe. The project team votes on each pair of risks based on the defined selection criteria. The CRR technique can become cumbersome with more than five to six risks.
The filtering, ranking, and CRR techniques can work together. First, you can use a filtering process to determine the most severe risks, then use the ranking technique to prioritize the list, and then use CRR for the last few risks the team is having difficulty prioritizing.
Ranking Prioritized Risks
Prioritized risks come in different shapes and sizes; some prioritized risks have specific impacts. However, not all risks can be quantified. For most risks, a simple judgment of rank ordering the risks can be done with input from the project team members.
Risk Response Planning
The third step in the risk management process is risk response planning, as shown in the following graphic. Risk response planning involves deciding what, if anything, should be done to mitigate each risk. Risk response planning is performed throughout the project and at each level in the Organizational Breakdown Structure where risks are identified. Risk response planning includes incorporating the risk mitigation actions into the project plans.
Risk response planning includes the following tasks:
- Assigning owners to individual risks. Ultimately, the project manager owns all risks, but risks can be delegated to others.
- Selecting the approach for dealing with individual risks or groups of related risks.
- Defining mitigation, contingency, and reserve plans.
Be aware that risk response planning can introduce new risks to the project. For example, if a risk is transferred to a supplier because that supplier has greater skill and expertise, a new dependency risk has been created. Mitigation or contingency plans for one risk might also make current risks more tolerable. When developing your risk response strategy, consider the combination of risks, ability of the team to implement the strategy, and the project constraints.
Follow this approach to plan your strategies to mitigate risk:
- Start with the most severe risks and proceed through the prioritized list of risks.
- Identify risk mitigation alternatives.
- Determine if risks can be grouped or categorized. The following list provides examples of grouping:
- By risk factor: A group of risks related to the contract type
- By consequence: A group of risks that might impact the delivery schedule, cost, quality, or customer satisfaction
- By mitigation alternatives: A group of risks that are affected by a single mitigation strategy, such as insurance or risk contingency reserve
- Evaluate alternatives based on risk categories, and select the primary options.
- Incorporate options into the project Risk Management Plan and into other project plans as needed.
Risk Response Options
Starting with the most severe risks, select the risk response options that will mitigate the risks with the lowest impact to the project.
Contain the Risk. The two types of risk containment are risk mitigation and risk contingency planning:
- Risk mitigation is taking steps now to lessen risk by either lowering the probability or reducing its effect.
- Risk contingency planning is developing a plan to define the actions to be taken if a risk consequence occurs.
- The sponsor or supplier through terms in the agreement (original or amended)
- An organization in a business unit not connected with the project through formal written documentation
- An organization in the same business unit as the delivery team through informal written documentation
Risk Triggers
Risk triggers are predefined thresholds for project status measurement that identify when a risk is about to occur. Effective triggers provide an early risk event warning so that project personnel can quickly implement the risk response plan to minimize project impact. Triggers should be incorporated into the project status reported in the project's reoccurring status meetings.
Some examples of triggers include the following events:
- Duration of a unit test for a software module exceeds the target by 20%
- Customer discusses reorganization
- Project critical dependency is behind schedule
- Code development is 50% complete at midpoint of schedule
Risk Management Plan
The Risk Management Plan includes the risk event description, mitigation, contingency, and reserve plans. In the following example of a Risk Management Plan, each row addresses a single risk with its rank, trigger, risk response plan, and owner of the response plan implementation. A single risk can have more than one planned response.
Make sure risk planning is made visible in the initial project review and to the sponsor, as appropriate. Only present risks to the sponsor if the sponsor needs to know or if the sponsor can affect the risk. Cost risks are not typically presented to the sponsor.
Risk Tracking and Control
Risk tracking and control is the fourth step in the risk management process, as shown in the following graphic. After the risks are analyzed, risk response options are assigned, and the Risk Management Plan is created, then the risks must be tracked. Data related to individual risks is collected, compiled, and analyzed to determine what, if any actions should be taken. Risk tracking depends on the availability of accurate, relevant, and timely risk-related data. More specifically, risk tracking and control rely on risk indicators and triggers, which are described in the section "Risk Triggers."
As part of risk tracking and control, perform the following activities:
- Implement and track the Risk Management Plan by acquiring and analyzing risk data for trends and effectiveness.
- Communicate the plan's status to project team members and other stakeholders.
- Continuously review mitigation, contingency, and reserve plans.
- Regularly identify new risks and update the Risk Management Plan.
Risk Reaction
Risk reaction is the fifth step in the risk management process, as indicated by the highlight on the React step of the graphic. Risk reaction includes executing risk responses and resolving risks as appropriate. A risk is resolved when it is no longer considered to be a significant threat to the project.
TIPS: The Importance of Risk Management
Before beginning a project, identify all major risks and your responses and contingency plans. When appropriate, have the client acknowledge the risks and agree to the responses. If the client disagrees with your approach, it is better to resolve the differences sooner rather than later.
Think about the triple constraints cost, schedule, and scope when you are identifying and analyzing risks. If one of the triple constraints changes due to a risk event, the other two elements are affected. Risk management helps you to reduce the impact of those risk events on each of the three constraints, helping to make your projects more successful.
The risk management plan enables you 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.
Finally, you don’t have to be the only person monitoring the risk triggers. Assign owners for each risk, ideally someone who is close to the work and can monitor the risk well ahead of it turning into a problem or issue. It is up to you to check that risk owners are performing their responsibilities as detailed in the risk management plan.
Completing the Project Plan
The completion of project plans is a significant milestone in the life cycle of a project. Completing the project plans includes defining requirements, shaping, estimating, and scheduling the project. At the end of the Planning Phase, the project manager commits to the completed plans, which will be used to measure actual project performance.
Considerations for Completing the Project Plan
This module focuses on the project plans and transaction documentation, such as a Statement of Work (SOW), the Document of Understanding (DOU), and the supporting project plans.
An agreement is a formal commitment between the project manager, the project manager's organization, and the project's sponsor. A documented and signed agreement is important project documentation. It provides a comprehensive definition of the commitments that the project must satisfy, plus the commitments of the sponsor and other key stakeholders. The structure and content of an agreement varies from project to project. Agreements with external sponsors usually require more detail and more scrutiny during reviews because they are legally binding contracts between the parties.
The agreement is referred to as the proposed agreement until both the delivery organization and the sponsor approve it. After the key issues are resolved, the agreement is approved. This approval authorizes the allocation of funds from the project sponsor and the assignment of resources from the delivery organization. The approval also freezes the agreement and supporting plans, which now form the project's baseline. The baseline is the criteria by which project performance is measured. If changes to the baseline are necessary, the change management process is used to update the agreement.
Approval of the key agreement typically happens after the planning or solution design phase. This time frame appears as a line after the Planning or Design phases in the following life cycle diagram. If the project is large or complex, each of the phases in the life cycle might be handled as a separate project within a program. If so, an agreement might be approved prior to each phase.
Completing the SOW
At this stage, the project manager has
reviewed the requirements and planned the project's implementation. The
organization is preparing to commit money, time, and resources.
Therefore, be sure that you understand and that you verify what is being
committed and what you should anticipate during the project.
Project managers should also perform the following activities:
- Document how to work with key project stakeholders to manage the project, including change management and managing the delivery of work products.
- Validate that the details in the project management system support the SOW commitments.
- Obtain commitment from key project team leads to complete their portions of the project plans, including verification that the schedule, cost, and quality commitments are achievable.
- Validate compliance with applicable standards, including the operating procedures of the delivery organization and sponsor's organization, local government laws, industry standards, and checkpoint review requirements defined in your business area, such as Quality Assurance, peers, and management.
- Ensure that the SOW is approved by the people who have the authority to allocate funds and resources to the project.
Completing the Financial Plans
Project managers need to understand
the financial aspects of the project, especially the baseline plan and
project measurements and how they are derived. One tip is to build a
relationship with the Accounting or Finance group to establish proper
procedures and processes, and to understand how the group reports
numbers. Then, in the Executing and Controlling phase, reconciling
ongoing performance and forecasting will be much easier to accomplish.
Continuous financial tracking leads to good decision making.
Depending upon the project, measurements might need to be met on monthly, quarterly, and annually milestone attainment basis. The interval and detail level of the measurements should match the needs of each stakeholder. These measurements differ from division to division, so project managers need to understand how they are used on their projects. An understanding of basic business measurement is necessary to manage the project.
Depending upon the project, measurements might need to be met on monthly, quarterly, and annually milestone attainment basis. The interval and detail level of the measurements should match the needs of each stakeholder. These measurements differ from division to division, so project managers need to understand how they are used on their projects. An understanding of basic business measurement is necessary to manage the project.
Typical financial measurements include the following:
- Revenue
- Project direct costs, other key costs might also be tracked, such as labor, travel, and capital.
- Gross profit
- Project indirect expenses, such as office information technology charges and rental fees
- Profit contribution
- Allocations, understanding these corporate fees is critical.
- Pretax income
Completing the Technical Environment Plan
The technical environment of the
project consists of a collection of hardware and network equipment,
software, and the equipment that is shared by the project team and used
to support a project.
The project management system must describe the technical environment needs and must validate that the technical environment architecture meets the proposed service level. The project manager should review the work facility, hardware, software, connectivity, passwords, and all details necessary to develop the project's technical environment. The technical environment plan includes how to acquire, install, establish, and even uninstall the environment.
Planning the technical environment is critical when the project is performed at a customer location. Because the availability of space, equipment, and support will involve customer commitment and personnel, these requirements should be reflected in the customer agreement.
The project management system must describe the technical environment needs and must validate that the technical environment architecture meets the proposed service level. The project manager should review the work facility, hardware, software, connectivity, passwords, and all details necessary to develop the project's technical environment. The technical environment plan includes how to acquire, install, establish, and even uninstall the environment.
Planning the technical environment is critical when the project is performed at a customer location. Because the availability of space, equipment, and support will involve customer commitment and personnel, these requirements should be reflected in the customer agreement.
The technical environment plan typically defines the following types of tools:
- An office suite that includes spreadsheet software, a word processor, presentation software, and drawing tools
- Office communications software for mail and access to shared office suite files
- Project management tools that support management and operational scheduling, time tracking, cost tracking, and risk management, and that provide access to the Project Control Book and to business systems
- Tools that support technical activities in all project phases
- Configuration management features that are associated with project management and technical tools
- The technical environment might already be in place before starting the project, need to be adapted, or need to be completely built. Project needs, costs, expected benefits, and risks must be carefully balanced before making a decision to build a technical environment or even to adapt one that already exists.
- The technical environment might be a deliverable that will be left behind or transferred to the sponsor at the end of the project.
- The technical environment might be provided by the sponsor or another supplier.
Root Causes of Troubled Projects
Over the years, extensive research has
been done to understand why projects fail to meet their
objectives. This research has revealed a relatively small set of common
root causes for all these project failures. These root causes can be
anticipated and avoided in project plans. For example, the failure to
understand customer requirements can be avoided by asking a lot of
questions about the scope definition documentation and talking with the
project sponsor about the sponsor's expectations before the agreement is
approved.
The root causes of troubled projects can be divided into the following categories.
Organizing the project:
- Failure to properly set and manage customer expectations
- Fixed price contracts used when and where they should not have been used
- Customer unprepared to take on the customer's project responsibilities
- Failure to reach a common understanding of the requirements
- Failure to reach a common understanding of the proposed solution
- Failure to establish appropriate contractual baseline
- Poorly constructed or unauthorized subcontracts
- Poor quality proposals or SOWs
- Failure to conduct independent proposal assurance reviews
Risk:
- Failure to adhere to published pricing guidelines, failure to assign adequate risk contingency, and improper investment pricing (unrealistically low pricing, low margins, and so on)
- Failure to plan for project risks
- Failure to properly use intellectual capital from previous engagement(s)
Estimation:
- Failure to adhere to published pricing guidelines, failure to assign adequate risk contingency, and improper "investment pricing" (unrealistically low pricing, low margins, and so on)
- Inaccurate project estimates
- Fixed-price contracts for combined phases
- Concessions during negotiations with no price increase
Schedules:
Inaccurate project estimates
Failure to plan for risk containment
Lack of transition plan from marketing to delivery
Inaccurate staffing plans
Insufficient test plans
Failure to properly use an approved methodology
TIPS: Validate the Project Plans
Similar to requirements validation, the
best way to avoid misunderstandings between you and your client is to
walk through the project plans. To avoid disputes later, be sure the
client has a clear understanding of how the plans meet their
requirements. Involve all the appropriate levels of the client’s
organization in this discussion. The goal is to obtain full concurrence
about the tasks, responsibilities, deliverables, completion criteria,
change control procedures, and schedule.
TIPS: Take Care of the Technical Environment
I have worked on projects where the
technical environment was poor: space was crowded, there were not enough
network connections and printers, and few phones. As a result, morale
was bad, and the project did not meet its budget and schedule. So pay
attention to the physical space and resources the project team will be
working with. You may have to take a leadership role and challenge the
normal way of doing business to create a work environment in which your
team can be high performing.
Monitoring and Controlling Projects
Project tracking and controlling are essential for effective project management. Continuous collection and evaluation of actual performance measurements in comparison with the baseline ensure effective communication and informed decision making. It also greatly reduces the risk of failed projects. You should use both progress and financial metrics to gain a true perspective of project status. Earned Value combines these measurements so that they can be compared.
The Importance of Controlling Projects
Project tracking and controlling are essential for effective project management. Continuous collection and evaluation of actual performance measurements in comparison with the baseline ensure effective communication and informed decision making. It also greatly reduces the risk of failed projects. You should use both progress and financial metrics to gain a true perspective of project status. Earned Value combines these measurements so that they can be compared.
The Importance of Controlling Projects
The project control cycle includes the following five elements:
- Establish a project management system for how the project will operate
- Collect actual project performance information
- Analyze and compare actual versus planned performance
- Adjust the project plans and take corrective action
- Communicate status and adjustment
Data Collection and Analysis
Collecting and analyzing project performance information provide important indicators for understanding project status.
The analysis step recognizes trends in past performance that can be used to predict how the project will perform in the future. The prior graphic illustrates gathering performance information.
Limits on variance to cost and schedule should be determined and agreed to by the sponsor and project team prior to beginning development. Measurements and tracking methods for scope and quality should be documented as part of the project Quality Plan.
Collecting Project Performance Information
Project managers should use a structured approach to collect project performance information. When determining the information to be collected, consider project attributes, such as critical success factors, sponsor's focus, project length, and complexity. The project manager must choose metrics that are appropriate to the specific project, the delivery organization, and the sponsor. Project metrics should meet the following criteria:
- Are trackable and measurable
- Span the life of the project
- Can be compared to the project's baseline measurements and critical success factors
- Are understood by the sponsor, team members, and other stakeholders
Project performance information is usually collected at specified intervals throughout the project life cycle. These intervals are generally coordinated with the intervals of project status meetings. For example, if regular status meetings are scheduled for each Wednesday, the project performance information might be collected on Tuesdays and summarized for the status meeting.
Project performance information should be archived as you progress through the project. This documentation might be needed later in the project for lessons learned and for explaining why a particular decision was made. In some failed projects, it might also provide the basis for negotiations.
Analyzing Project Performance Information
The purpose of analyzing project performance information is to compare actual performance to the baseline plan and to predict future project performance. Project managers need this analysis to determine what, if any, corrective adjustments need to be made to the project plans. Project performance analysis is also a powerful communication tool. Different stakeholders require different information. The project manager must filter and summarize the information to suit each stakeholder audience. This information must be provided in a timely manner with honest and accurate representations of the project's progress and any variances.
The following guidelines apply to collecting and analyzing project performance information for status meetings:
- Project performance information should include aspects of the project, such as suppliers, issues, action items, deliverables, quality management, risk management, technical environment management, and change management.
- Focus on project performance information since the last status meeting, and then predict performance for the next three status meeting periods.
- Validate the correctness and completeness of project performance information.
- Identify completed work and support people doing a good job.
- Avoid analyzing a single measurement in isolation.
- Metrics should be compared to one another to gain a true perspective of project performance.
- Identify any variances and explain the effect on the schedule and budget, the corrective action, and the corrective action owner.
- Evaluate work that will start or finish in the next status reporting period.
- Track issue resolution.
- Archive project performance information, analysis, and status meeting reports in the Project Control Book.
Progress Measurements
Progress measurements are used to determine the status of the actual work against the baseline schedule. The tracking method used depends upon how the work was planned and how the success of the project is assessed. Two primary methods are used for tracking progress:
Effort-based method
The effort-based method is used to measure the actual number of hours spent on each task against the planned number of hours. The effort-based method is used when managing large teams, when labor hours are closely managed, and when cost recovery is a key measure of project success. The measurement unit is usually person-hours.
Duration-based method
The duration-based method is used to measure task completions against the project baseline schedule. This method is used when the project team members are assigned to a project based upon a percentage of their time over a particular calendar duration. For example, developers might be assigned to a project for 50% of their time over a 6-month period; they must complete their tasks within those 6 months. The duration-based method can measure each task completion in a binary manner, such as complete or incomplete, or measure the percentage that is complete for each task.
In the duration-based method, the length of the tasks in the baseline schedule affect the accuracy of the schedule's progress measurement during implementation. Project managers depend on task owners to report their progress toward the completion of tasks. Therefore, the length of the tasks determines +/- accuracy of the overall schedule measurement. For example, in a schedule where the tasks are 40 hours or less, the project manager uses task completions to determine the progress against the schedule within a tolerance of +/- 40 hours. This is why it is particularly important to keep tasks below the 40-to-80 hour guideline.
The following graphs are examples of schedule progress measurements. In the first graph, tracking the critical path focuses on the key tasks that are driving the project schedule. In the second graph, personnel loading is used as an indicator of cost variance because of labor and schedule variances.
Financial Measurements
The purpose of financial tracking is to assess the project cost. In some business areas, it is also used to assess the profit and revenue variances from the baseline plan. Financial accounting is a complex discipline. As a project manager, you need to track financial data at the project level by using the business area's accounting system. The accuracy of the project's financial measurement depends upon the accounting system's level of detail, availability of project-specific reports, reporting period interval, and other factors.
Financial data includes the following elements:
Project cost-related data, such as the following costs:
- Salaries and related costs
- Costs for provided staff
- Travel and living expenses
- Supplier payments
- Hardware costs
- Software costs
- Training costs
- Office space charges
- Material costs (for example, office supplies and books)
Revenue generated from customer purchases:
Earned Value Overview
To understand the true status of a project, project managers must combine the progress measurements and financial measurements. Using either the progress measurements or the financial measurements by themselves can lead to a misleading picture of project status. For example, do the following measurements indicate good news about project status?
The Earned Value analysis method combines progress measurements and financial measurements into one format where they can be compared with the baseline to determine the true status of the project. It does this by translating schedule measurements into financial measurements, so that they can be compared. The Earned Value analysis method also predicts future project trends. After a project is 20% completed, Earned Value is a fairly reliable predictor of future project performance. However, at the 20% completed point in the project, it is very difficult to align with the baseline.
The Earned Value indicators are somewhat complex, so they are generally calculated at the activity level or phase level. They are usually reported on a monthly interval or at significant project milestones.
Using Earned Value to Determine Project Status
Earned Value has its own vocabulary. Because some of the vocabulary was changed by PMI® in 2002, the old terminology, which is still widely used, is also provided for your reference. One way to understand and remember all these measurement terms is to relate them to the questions they answer.
Baseline
The following terms relate to the Earned Value baseline:
- Hardware price
- Software price
- Services price
- Staff labor revenue (price billed to customer)
Earned Value Overview
To understand the true status of a project, project managers must combine the progress measurements and financial measurements. Using either the progress measurements or the financial measurements by themselves can lead to a misleading picture of project status. For example, do the following measurements indicate good news about project status?
- Project A's progress measurement shows the project is 2 weeks ahead of the baseline schedule.
- Project B's financial measurement shows the project costs are 10% below the baseline.
- Project A is 2 weeks ahead, but your financial measurement shows your team has been working overtime, and their overtime labor premium has put the project 15% over budget.
- Project B is 10% below budget, but your progress measurement shows you are 20% behind on task completions. This means you are behind schedule and actually over budget!
The Earned Value analysis method combines progress measurements and financial measurements into one format where they can be compared with the baseline to determine the true status of the project. It does this by translating schedule measurements into financial measurements, so that they can be compared. The Earned Value analysis method also predicts future project trends. After a project is 20% completed, Earned Value is a fairly reliable predictor of future project performance. However, at the 20% completed point in the project, it is very difficult to align with the baseline.
The Earned Value indicators are somewhat complex, so they are generally calculated at the activity level or phase level. They are usually reported on a monthly interval or at significant project milestones.
Using Earned Value to Determine Project Status
Earned Value has its own vocabulary. Because some of the vocabulary was changed by PMI® in 2002, the old terminology, which is still widely used, is also provided for your reference. One way to understand and remember all these measurement terms is to relate them to the questions they answer.
Baseline
The following terms relate to the Earned Value baseline:
Schedule Progress Measurement
After the baseline has been defined, the next step is to add the actual schedule performance metrics to the earned value picture:
- Earned Value (EV) is probably the most difficult measurement to understand. EV indicates schedule progress, but EV measures it in financial terms. Each task in a project schedule has an estimated baseline cost. As each task is completed, its baseline cost is added to EV. In other words, EV measures the amount of customer value that each task completion earns. For example, assume there are 5 tasks that should be completed in your project by now. The baseline cost for each task is $100. If your project is on schedule, all 5 tasks would be complete and your EV would be $500. If your project had only completed 3 of the tasks, you would be behind schedule and your EV would be $300. EV answers the question, How much of the baseline schedule has been accomplished? The old name for EV was Budgeted Cost of Work Performed (BCWP).
- Schedule Variance (SV) is used to measure the difference between the baseline schedule (EV) and the actual schedule performance (PV). SV answers questions like, What is the difference between what was accomplished and what was scheduled? The formula for SV is: EV - PV. If SV is negative, then the project is behind schedule. If SV is positive, then the project is ahead of schedule.
- Schedule Performance Index (SPI) is the ratio of EV to PV. another way to show the difference between PV and EV. The formula for SPI is: EV / PV, if SPI is over 1.0, the project is ahead of schedule. If SPI is under 1.0, it is behind schedule.
- Percent Complete (% complete) indicates how much of the entire project schedule has been completed. The formula for % complete is: EV / BAC.
Financial Progress Measurement
After the schedule progress measurements have been calculated, the next step is to add the actual financial performance. These metrics are similar to the schedule progress measurements:
- Actual Cost (AC) is the actual cost of the work that was completed. AC answers questions like, How much did it really cost to perform the work? and How much has been spent against plan? If AC is higher than the baseline EV, the project is over budget. If AC is lower than EV, the project is under budget. The old name for AC was Actual Cost of Work Performed (ACWP).
- Cost Variance (CV) is used to measure the difference between the planned cost of work performed (EV) and the Actual Cost of Work Performed (AC). CV answers questions like, Am I over or under budget? The formula for CV is: EV - AC. If CV is positive, the project is under budget. If CV is negative, the project is over budget.
- Cost Performance Index (CPI) is another way to show the difference between AC and EV. The formula for CPI is: EV / AC. If CPI is over 1.0, the project is under budget. If CPI is under 1.0, it is over budget.
- Percent Spent (% spent) indicates how much of the entire project budget has been spent. The formula for % spent is: AC / BAC.
Using Earned Value to Predict Project Performance
Earned Value can also be used to predict how the project will perform in the future. Remember that these are just estimates based upon past project trends. Other project factors might cause the estimates to be significantly off track.
Estimate to Complete
Estimate to Completion (ETC) predicts how much more it will cost to complete the project. There are several ways to estimate ETC:
In the early project phases, the project plans were created using estimating assumptions. These estimates might have been generated by expert judgment or past experience on similar projects. As more is learned during the implementation of the project, the estimates should be periodically reviewed for accuracy. The plan adjustment includes these steps:
The Communications Management Plan includes the following information:
The following guidelines apply to creating a Communication Management Plan:
The Communications Management Plans should answer the following questions:
If all stakeholders try to communicate with all other stakeholders, the project will be impacted by a flood of e-mails, conference calls, online chats, and other communications. The number of communication paths increases at an exponential rate as each new stakeholder is added. With all of these communication paths, it is difficult to ensure that the information being communicated is consistent and up-to-date. Inconsistent and out-of-date information causes great confusion and takes additional time to resolve.
One of the key values of communication planning is to determine which communication paths are necessary for an efficient project and to limit the paths that are not necessary. In other words, a good communication plan reduces the flood of communications and saves time for stakeholders. For example, only the project manager should report project status to the sponsor. The following formula can be used to calculate the number of communication channels. N is the number of stakeholders.*
N x (N-1) / 2
The following table shows how communication paths grow as the number of stakeholders increases.
*See J. Davidson Frame,Managing Projects in Organizations: How to Make the Best Use of Time, Techniques, and People , rev. ed. (San Francisco: Jossey-Bass, 1995).
Project Control Book
The Project Control Book contains organized output from the execution of the project management plan. As a project progresses through its life cycle, it produces lots of documentation. The documentation that is created in the early phases of a project is usually the basis for later project documentation. This accumulated documentation becomes the backbone of the project and is key to coordinating project activities. Therefore, it is critical that key project documentation be archived and controlled in a Project Control Book. The project manager's responsibilities include maintaining a current Project Control Book. During a project audit, one of the first inquiries is about the Project Control Book.
Project Status Reporting
The purpose of reporting is to inform project stakeholders of the project status by comparing actual project performance to the baseline. Status reports are a key input to stakeholders when deciding what, if any, corrective actions should be taken. The form, content, and frequency of reports vary depending on the nature of the project and the audience for which they are intended.
In general, reports should meet the following criteria:
Format and Flow of Status Reports
Periodically, all project managers, team leaders, and individuals produce the status reports defined in the project's Communication Management Plan. Individual status reports should be formatted so that they can be easily summarized as the information flows upward to key stakeholders in the Organizational Breakdown Structure.
The sequence of regular meetings and communiqués is the spark that drives good communication among all the stakeholder levels. For example, individuals might report status on Monday, then their team leader holds a team status meeting on Tuesday, then the team leaders create their status for the project manager's meeting on Wednesday, and then the project manager conducts a project status meeting with senior management on Thursday. After this upward flow of status, the project manager should immediately follow up with a note to the team about any urgent feedback from the management team. Also, the project manager works with suppliers to establish a status reporting methodology. Your supplier should provide status information in a format similar to other project contributors.
The following levels of reporting are typical:
The Project Status Report is used to report the status to senior management and project sponsors. It is important to understand the limitations and formatting capability of the automated reporting system that you use. Try to format the regular reports to minimize the amount of manual data manipulation effort. Be sure to verify that the financial reporting system provides metrics that are useful at the work unit or project level.
Assessment of Project Status
As a project manager, you should be able to answer the following questions during project status reviews:
Types of Project Performance Information and Analysis
The combination of progress and financial data is needed to understand the true status of how a project is performing:
TIPS: Communicate Early and Often
Virtually every project has some bad news that has to be told to the client. Inform the client about the “bad news” as early as possible. Of course, the client will also expect you to bring some alternative solutions to the problem. In many circumstances, the client will help develop the solution. And sometimes, what you think of as bad news is not considered that bad by the client, if you present it tactfully and candidly.
Good communications help you maintain stakeholder commitment and manage expectations. Be sure to communicate progress and status to all stakeholders.
Back in the contracting section, I mentioned the need for you to schedule periodic project reviews. These reviews are conducted to help your project be successful. It is your responsibility to make sure the action plans resulting from these reviews are put into place.
Managing Change
The project manager must demonstrate leadership in the change management process by the following actions:
Change occurs on almost every project. Poor change management is the single most common root cause of troubled projects. Therefore, the management of change is critical to the success of a project. A change is anything that can impact the project's baseline cost, schedule, scope, risk, and resources. Changes might affect the following areas of the project:
Change on a project is not always bad. As the project develops, additional information is learned that can improve product or service quality, efficiency, cost, and customer satisfaction. A change might also earn additional revenue for the project.
Therefore, do not try to avoid changes, just manage them. Change management includes the following key elements:
Project managers are responsible for tailoring the change management process to the needs of their project. The change management process includes the following elements:
Changes can be introduced by the sponsor, supplier, delivery organization, or a member of the project. Changes might be contractual or technical, or they might arise from market conditions. Contractual changes are usually easy to identify because they involve changes in the contract, terms, or conditions. Small technical changes might not be as obvious. All changes need to be documented so that any differences from the original approach are recorded. The following graphic summarizes these sources of changes.
It is the project manager's responsibility to ensure that everybody understands and follows the change management process. The sponsor and subcontractor agreements should also include a high-level description of the change management process.
Scope Creep
Scope creep refers
to a gradual accumulation of changes that result in a major impact on
the project. These changes can be small, subtle events. Each of these
small events might not affect the baseline on its own, but the
accumulation of many small changes can add up to significant project
impacts.
These small changes also need to be identified and managed throughout the life cycle of the project. In the change management process, small changes can be tracked and then grouped together into a single Change Request to reduce unnecessary paper work.
The change management process might also delegate change requests under certain thresholds to be approved by the project manager.
Project Baselines
The formal management of baselines is an important aspect of change control. When change is not managed, project scope often increases without considering how the changes affect milestones and cost.
The baseline defines requirements, cost, and schedule that have been committed to by the project manager, delivery organization, and the sponsor. Requirements, cost, and schedule are often called the triple constraints. Each parameter is highly affected by the other two. For example:
When changes occur, the project manager must often perform a trade-off analysis on the triple constraints to find the best balance for the project.
he project baseline is documented in the sponsor agreement and other technical and project management work products. While implementing the project plan, project managers receive many requests and lots of status reports. Project managers use this information to distinguish between in-scope adjustments and out-of-scope changes. The baseline must be defined to a level of detail so that changes can be recognized as they occur. The baseline should clearly define the triple constraints in a measurable way. For example, the baseline should include specific completion criteria for each deliverable, deliverable milestone dates, payment amounts, and due dates.
Key Steps in the Change Management Procedure
The change management process defines the steps by which each Change Request is submitted, analyzed, and approved.
For each Change Request, the project manager drives the decision-making process and ensures that all the stakeholders who might be impacted by the change are informed.
The following flow chart shows a typical change management procedure.
The Role of the Project Manager in Managing Change
Establishing the Change Management Process
It is the project manager's responsibility to ensure that the project has a change management process. The change management process in the delivery organization can be used, or the sponsor might request that you use the sponsoring organization's process. The change management plan and procedures should be included in your baseline project plans.
To appear less bureaucratic, project managers are sometimes tempted to handle changes informally instead of using a formal change management process. Not having a formal change control process leads to misunderstandings, additional costs, and difficulty meeting the project schedule. The change management process does not need to be complex; however, it should be documented and followed.*
The project manager is also responsible for ensuring that a change control board (CCB) is established to approve, reject, or defer Change Requests. The project manager should be a member of the CCB. Project managers also need to define what changes they are authorized to approve.
Implementing the Process
All members of the team participate in the change control process, so the project manager should demonstrate leadership in the change management process in the following ways:
The project manager has specific responsibilities for the following activities within the change management process:
Personality Traits
Research shows that there are patterns in most people's personalities, behavior, and how they interact within a team. These traits can be analyzed to predict and improve your project team members' performance. This section discusses the most widely accepted analysis tools and theories:
Earned Value can also be used to predict how the project will perform in the future. Remember that these are just estimates based upon past project trends. Other project factors might cause the estimates to be significantly off track.
Estimate to Complete
Estimate to Completion (ETC) predicts how much more it will cost to complete the project. There are several ways to estimate ETC:
- Sum the baseline costs for the unfinished work units. This is a fast way to calculate ETC, but it does not use experience-to-date gained from this project. For example, we may have a productive team that has so far surpassed the original estimates.
- Re-estimate each of the unfinished work units. This is a more accurate method, but it is time consuming.
- Use the Earned Value measurements to predict ETC. This method is fast and uses past project experience. The ETC formula is (BAC / CPI) - AC.
Estimate at Completion
Estimate at Completion (EAC) is the
predicted cost for the entire project. In other words, it is actual
costs (AC) plus predicted costs (ETC). The EAC formula is ETC + AC.
Using Earned Value Data for Project Control
Earned Value is a logical approach
to monitoring and controlling projects. The following steps are the key
steps in Earned Value analysis:
- Establish a baseline for the project's planned performance (PV and BAC).
- Collect progress and financial project data (EV and AC).
- Calculate the schedule progress measurements (SPI, SV, and % complete).
- Calculate the financial progress measurements (CPI, CV, and % spent).
- Forecast the performance through project completion (ETC, EAC, VAC, and TCPI).
- Review any cost variances at the project level.
- If there is a significant variance, investigate the details to discover the root cause.
- Determine the corrective actions that are needed, and update the project plans.
- Implement the action plan.
Project Plan Adjustments
The purpose of monitoring and
forecasting project performance is to find variances while they are
still small and to take actions to bring the project back into alignment
with baselines.
Monitoring and Forecasting Project Performance
In the early project phases, the project plans were created using estimating assumptions. These estimates might have been generated by expert judgment or past experience on similar projects. As more is learned during the implementation of the project, the estimates should be periodically reviewed for accuracy. The plan adjustment includes these steps:
- Review the cost and schedule variances.
- Analyze the trends.
- Forecast the impact on the project milestones, cost, and resources.
- Among the variances, identify those that have the greatest impact, such as the following ones:
- The largest absolute or relative variances
- Variances on activities on the critical path
- Variances that have increased from the previous tracking period
Investigating and Eliminating the Root Cause for any Variances
Because a variance is a symptom of a problem, you should investigate the root causes of the variance before making a project plan adjustment. Root causes might include system problems, late delivery of an external dependency, poor work practices, lack of training, and other causes. Among the variances, start with those that have the greatest impact. Use a top-down assessment, that is, starting from high-level activities and moving to lower-level activities while looking for the following variances:
Adjusting the Plans
The purpose of this activity is to adjust the project plans when a variance occurs and to bring the project back into alignment.
Adjusting the plan includes the following tasks:
Corrective Actions
Cost-corrective actions include the following examples:
Issue Management
The purpose of issue management is to maintain control of project implementation by collecting issues, determining resolution actions, and then monitoring their progress through closure. Project managers are responsible for championing the issue management process and resolving issues from the project team, suppliers, management, and the sponsor.
An issue is a generic term for a matter of concern on a project. Issues are unplanned events that occur during a project and that require resolution. An issue could be a warning of impact to the cost, schedule, scope, or customer satisfaction.
Each issue requires a response. Issue resolution might occur immediately, or the issue might require a lengthy amount of analysis to resolve. The response might be only an answer if the issue is a request for information, a choice or decision, and one or more corrective actions.
Issue management includes the following activities:
Communications Management
Effective communication is a prerequisite for a smoothly functioning project team. The following graphic identifies the roles with which the project manager might communicate.
The communication needs of each project vary with the stakeholders, organization, and unique project attributes. Communications planning is particularly important for geographically dispersed teams. Each project should have a Communications Management Plan that describes the key types of information to be shared, shows who provides each type of information, and lists with whom the information is shared. It is the project manager's responsibility to create and implement the Communications Management Plan.
The Communications Management Plan is created early in the project life cycle along with the other project plans.
Because a variance is a symptom of a problem, you should investigate the root causes of the variance before making a project plan adjustment. Root causes might include system problems, late delivery of an external dependency, poor work practices, lack of training, and other causes. Among the variances, start with those that have the greatest impact. Use a top-down assessment, that is, starting from high-level activities and moving to lower-level activities while looking for the following variances:
- Variances because of a major disruption (for example, a procedure not working satisfactorily or badly defined boundaries between subprojects)
- Largest absolute or relative variances on cost, time, and effort
- Variances on activities of the critical path
- Variances that have increased from the previous tracking period
- Are the variances likely to continue or was it just a one-time occurrence?
- Are the variances caused by team performance, technology, methodology, or project complexity?
- Are the variances because of scope creep? (Scope creep is small, undocumented changes that have accumulated.)
- Which root causes can be mitigated?
- Could an independent review help to identify root causes?
- Should project controls and procedures be improved?
- Do the staff skill and experience levels meet the needs of the project?
Adjusting the Plans
The purpose of this activity is to adjust the project plans when a variance occurs and to bring the project back into alignment.
Adjusting the plan includes the following tasks:
- Identify key constraints to project adjustments, such as availability of current resources or rigid process requirements.
- Define and prioritize any new project objectives
- Find the most balanced plan adjustment; for example, adjustments to improve the schedule might have a significant impact on costs.
- Minimize the impact of the adjustments. (When possible, these corrective actions should be within the scope of the sponsor and subcontractor agreements.)
- If necessary, replan the project when there is a gross variance in the estimating assumptions. (If a project is moving from an Approved Baseline Cost (BAC) to a higher Estimated Cost at Completion (EAC), the EAC should be supported by a bottom-up Estimate to Complete (ETC).)
- Propose and gain agreement on any plan adjustments.
- Ensure that the updated plans remain realistic.
- If necessary, submit a change request.
Corrective Actions
Cost-corrective actions include the following examples:
- Reduce requirements.
- Reduce labor rates by reassigning work to lower cost staff.
- Reduce paid overtime.
- Improve the design.
- Improve processes.
- Eliminate unnecessary tasks.
- Implement shift work or overtime.
- Add staff, or contract for some work.
- Improve tools or processes.
- Improve the skills of the staff.
- Overlap some tasks, perhaps by crashing the schedule.
Issue Management
The purpose of issue management is to maintain control of project implementation by collecting issues, determining resolution actions, and then monitoring their progress through closure. Project managers are responsible for championing the issue management process and resolving issues from the project team, suppliers, management, and the sponsor.
An issue is a generic term for a matter of concern on a project. Issues are unplanned events that occur during a project and that require resolution. An issue could be a warning of impact to the cost, schedule, scope, or customer satisfaction.
Each issue requires a response. Issue resolution might occur immediately, or the issue might require a lengthy amount of analysis to resolve. The response might be only an answer if the issue is a request for information, a choice or decision, and one or more corrective actions.
Issue management includes the following activities:
- Collecting and logging issues.
- Performing an initial issue analysis to determine the resolution actions.
- Ensuring that the issue is investigated and that the action plan is documented. All action plans should have owners and due dates.
- Monitoring the progress of issue resolution to ensure that issues are progressing toward resolution.
- Establishing and analyzing issue resolution statistics. The project manager summarizes issue status and reports it to key stakeholders.
Communications Management
Effective communication is a prerequisite for a smoothly functioning project team. The following graphic identifies the roles with which the project manager might communicate.
The communication needs of each project vary with the stakeholders, organization, and unique project attributes. Communications planning is particularly important for geographically dispersed teams. Each project should have a Communications Management Plan that describes the key types of information to be shared, shows who provides each type of information, and lists with whom the information is shared. It is the project manager's responsibility to create and implement the Communications Management Plan.
The Communications Management Plan is created early in the project life cycle along with the other project plans.
The Communications Management Plan includes the following information:
- The processes required to best address timely and appropriate collection, generation, dissemination, storage, and disposition of project information
- The critical communication links among stakeholders
- Communications both external and internal to the project team
- The reoccurring meetings, reporting, and communiques
The following guidelines apply to creating a Communication Management Plan:
- Do not assume that all communication links are functioning effectively because people are communicating with one another.
- Review the sponsor's agreement, the supplier's agreements, and the project definition.
- Review the Project Decision Structure and the Organizational Breakdown Structure to determine any official communication channels.
- Review the organization's and project's procedures to understand the status reporting and status meeting requirements. Policies and procedures of the delivery organization often define the format and procedures for status meetings and status reporting.
- Interview key project stakeholders to understand their formal and informal communication needs and channels.
- Interview project managers who might have prior experience with the sponsor or the delivery organization's management.
- Review the Technical Environment Plan to identify the information technology (IT) options that are available to the project team, the sponsor, and the supplier.
- Determine the most effective methods and channels to share each type of information in addition to the provider and receiver of the information.
- Document the Communications Management Plan.
The Communications Management Plans should answer the following questions:
- For each type of information, does it need to be passed just one way, or is it a two-way communication?
- Is the project team co-located, or are they geographically dispersed across long distances, time zones, or organizations?
- What formal reports are needed to satisfy each stakeholder?
- What meetings are needed to satisfy each stakeholder? Types of meetings include all-hands (the entire project team), one-on-one (or face-to-face), and conference calls.
- What common tools and technologies will be used for formal and informal communications? Examples include chat tools, word processing software, and presentation software. Tool version levels might also need to be specified to ensure compatibility among stakeholders.
What information archival systems are needed
for the technical and project management work products? Informational
archival systems include Project Control Books, databases, groupware,
and manual filing systems.
Communication Paths
Communication Paths
If all stakeholders try to communicate with all other stakeholders, the project will be impacted by a flood of e-mails, conference calls, online chats, and other communications. The number of communication paths increases at an exponential rate as each new stakeholder is added. With all of these communication paths, it is difficult to ensure that the information being communicated is consistent and up-to-date. Inconsistent and out-of-date information causes great confusion and takes additional time to resolve.
One of the key values of communication planning is to determine which communication paths are necessary for an efficient project and to limit the paths that are not necessary. In other words, a good communication plan reduces the flood of communications and saves time for stakeholders. For example, only the project manager should report project status to the sponsor. The following formula can be used to calculate the number of communication channels. N is the number of stakeholders.*
N x (N-1) / 2
The following table shows how communication paths grow as the number of stakeholders increases.
| Stakeholders | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
|---|---|---|---|---|---|---|---|---|---|
| Communication paths | 1 | 3 | 6 | 10 | 15 | 21 | 28 | 36 | 45 |
*See J. Davidson Frame,
Project Control Book
The Project Control Book contains organized output from the execution of the project management plan. As a project progresses through its life cycle, it produces lots of documentation. The documentation that is created in the early phases of a project is usually the basis for later project documentation. This accumulated documentation becomes the backbone of the project and is key to coordinating project activities. Therefore, it is critical that key project documentation be archived and controlled in a Project Control Book. The project manager's responsibilities include maintaining a current Project Control Book. During a project audit, one of the first inquiries is about the Project Control Book.
Project Status Reporting
The purpose of reporting is to inform project stakeholders of the project status by comparing actual project performance to the baseline. Status reports are a key input to stakeholders when deciding what, if any, corrective actions should be taken. The form, content, and frequency of reports vary depending on the nature of the project and the audience for which they are intended.
In general, reports should meet the following criteria:
- Provides timely, complete, and accurate status information
- Warns of pending problems so that corrective actions can be taken
- Is straightforward to create and easy to understand
- Is suited to their audience
- Is compliant with the policies of the delivery organization’s business unit
- Status information that describes where the project stands as compared to the baseline plan
- Progress information that describes what the project has accomplished since the last report, such as milestones and deliverables that were completed
- Forecast information that predicts future performance and project activities, such as estimated effort, cost, and schedule completions
- Risks, issues, and action items
- Recommendations for corrective actions and plan adjustments, when needed
- Information about quality that compares deliverables with their acceptance criteria, and possibly including the results of independent assessments
Format and Flow of Status Reports
Periodically, all project managers, team leaders, and individuals produce the status reports defined in the project's Communication Management Plan. Individual status reports should be formatted so that they can be easily summarized as the information flows upward to key stakeholders in the Organizational Breakdown Structure.
The sequence of regular meetings and communiqués is the spark that drives good communication among all the stakeholder levels. For example, individuals might report status on Monday, then their team leader holds a team status meeting on Tuesday, then the team leaders create their status for the project manager's meeting on Wednesday, and then the project manager conducts a project status meeting with senior management on Thursday. After this upward flow of status, the project manager should immediately follow up with a note to the team about any urgent feedback from the management team. Also, the project manager works with suppliers to establish a status reporting methodology. Your supplier should provide status information in a format similar to other project contributors.
The following levels of reporting are typical:
- Individual status reports are produced by technical contributors, and the reports describe results at the work item level.
- Subproject and team or supplier status reports are produced by subproject project managers or team leaders to describe results at the activity or phase level.
- The top-level project manager aggregates lower-level information and adds in subcontractor status information at the appropriate level to produce the Project Status Report.
The Project Status Report is used to report the status to senior management and project sponsors. It is important to understand the limitations and formatting capability of the automated reporting system that you use. Try to format the regular reports to minimize the amount of manual data manipulation effort. Be sure to verify that the financial reporting system provides metrics that are useful at the work unit or project level.
Assessment of Project Status
As a project manager, you should be able to answer the following questions during project status reviews:
- Where should I be?
- How much has been done?
- How much did it cost?
- What has been accomplished?
- Has each deliverable met its completion criteria? (Project managers should reject deliverables that do not comply with contract provisions.)
- How much will it take to finish (cost, schedule, and resources)?
- What will it cost when it is finished?
- Do I have enough resources to finish?
- What are the risks in getting to completion?
- What are the problems and issues that must be addressed?
- Will they likely affect one or more of these questions?
- Is there a free, nonthreatening environment for reporting issues and identifying future obstacles and opportunities?
- Is the status that is given to me timely, honest, and accurate?
Types of Project Performance Information and Analysis
The combination of progress and financial data is needed to understand the true status of how a project is performing:
- Progress information is used to assess accomplishments and effort estimates against the baseline schedule. This is an indicator of the accuracy of the estimates and adequacy of resources. This information might lead to replanning the remaining activities of the project. Examples of progress information are task completions, effort, and duration.
- Financial information provides a comparison of cost expenditures and revenues against the baseline.
TIPS: Communicate Early and Often
Virtually every project has some bad news that has to be told to the client. Inform the client about the “bad news” as early as possible. Of course, the client will also expect you to bring some alternative solutions to the problem. In many circumstances, the client will help develop the solution. And sometimes, what you think of as bad news is not considered that bad by the client, if you present it tactfully and candidly.
Good communications help you maintain stakeholder commitment and manage expectations. Be sure to communicate progress and status to all stakeholders.
Back in the contracting section, I mentioned the need for you to schedule periodic project reviews. These reviews are conducted to help your project be successful. It is your responsibility to make sure the action plans resulting from these reviews are put into place.
Managing Change
The project manager must demonstrate leadership in the change management process by the following actions:
- Establish and implement a change management process that fits the project's needs.
- Ensure that key approvers understand and agree with the steps in the change management procedure.
- Establish a change control board.
- Integrate all members of the team into the change management process.
- Keep Change Requests and the Change Logs updated to ensure that changes are processed in an expeditious manner.
Change occurs on almost every project. Poor change management is the single most common root cause of troubled projects. Therefore, the management of change is critical to the success of a project. A change is anything that can impact the project's baseline cost, schedule, scope, risk, and resources. Changes might affect the following areas of the project:
- The technical work
- The agreement with the sponsor, a supplier, or a performing organization
- The project management plans
- The procedures
Change on a project is not always bad. As the project develops, additional information is learned that can improve product or service quality, efficiency, cost, and customer satisfaction. A change might also earn additional revenue for the project.
Therefore, do not try to avoid changes, just manage them. Change management includes the following key elements:
- A well-defined project baseline
- A change management process that explains how to handle change requests and describes key responsibilities
- Assurance that all changes follow the process
- A project manager who champions and drives the change requests through the change management process
Project managers are responsible for tailoring the change management process to the needs of their project. The change management process includes the following elements:
- The formal, documented procedure that defines the steps for managing change requests.
- The established tracking system and approval levels necessary to authorize Change Orders. Procedures to handle small changes in a more streamlined manner should also be included.
Changes can be introduced by the sponsor, supplier, delivery organization, or a member of the project. Changes might be contractual or technical, or they might arise from market conditions. Contractual changes are usually easy to identify because they involve changes in the contract, terms, or conditions. Small technical changes might not be as obvious. All changes need to be documented so that any differences from the original approach are recorded. The following graphic summarizes these sources of changes.
It is the project manager's responsibility to ensure that everybody understands and follows the change management process. The sponsor and subcontractor agreements should also include a high-level description of the change management process.
Scope Creep
These small changes also need to be identified and managed throughout the life cycle of the project. In the change management process, small changes can be tracked and then grouped together into a single Change Request to reduce unnecessary paper work.
The change management process might also delegate change requests under certain thresholds to be approved by the project manager.
Project Baselines
The formal management of baselines is an important aspect of change control. When change is not managed, project scope often increases without considering how the changes affect milestones and cost.
The baseline defines requirements, cost, and schedule that have been committed to by the project manager, delivery organization, and the sponsor. Requirements, cost, and schedule are often called the triple constraints. Each parameter is highly affected by the other two. For example:
- If the requirements increase, the cost or the schedule might need to expand to cover the additional scope.
- If a request to accelerate a project is received, the project manager has several options. The resources could be increased, but that will probably increase cost. Some of the less critical requirements could be dropped or deferred, but the projects goals might not be met.
When changes occur, the project manager must often perform a trade-off analysis on the triple constraints to find the best balance for the project.
he project baseline is documented in the sponsor agreement and other technical and project management work products. While implementing the project plan, project managers receive many requests and lots of status reports. Project managers use this information to distinguish between in-scope adjustments and out-of-scope changes. The baseline must be defined to a level of detail so that changes can be recognized as they occur. The baseline should clearly define the triple constraints in a measurable way. For example, the baseline should include specific completion criteria for each deliverable, deliverable milestone dates, payment amounts, and due dates.
Key Steps in the Change Management Procedure
The change management process defines the steps by which each Change Request is submitted, analyzed, and approved.
For each Change Request, the project manager drives the decision-making process and ensures that all the stakeholders who might be impacted by the change are informed.
The following flow chart shows a typical change management procedure.
The Role of the Project Manager in Managing Change
Establishing the Change Management Process
It is the project manager's responsibility to ensure that the project has a change management process. The change management process in the delivery organization can be used, or the sponsor might request that you use the sponsoring organization's process. The change management plan and procedures should be included in your baseline project plans.
To appear less bureaucratic, project managers are sometimes tempted to handle changes informally instead of using a formal change management process. Not having a formal change control process leads to misunderstandings, additional costs, and difficulty meeting the project schedule. The change management process does not need to be complex; however, it should be documented and followed.*
The project manager is also responsible for ensuring that a change control board (CCB) is established to approve, reject, or defer Change Requests. The project manager should be a member of the CCB. Project managers also need to define what changes they are authorized to approve.
Implementing the Process
All members of the team participate in the change control process, so the project manager should demonstrate leadership in the change management process in the following ways:
- Champion: Defend baselines with integrity.
- Facilitator: Encourage contributions from the appropriate team members.
- Advocate: Support new ideas and opportunities.
- Mediator: Resolve conflict for the greater good.
The project manager has specific responsibilities for the following activities within the change management process:
- The project manager must determine the impact of the change by screening the Change Requests.
- The project manager must ensure that all appropriate stakeholders have participated in the impact analysis for the Change Request.
- The project manager is responsible for scope management. The project manager must assess the effect of the change in terms of project risk and the project baselines. As changes are accepted and incorporated, the project documentation must be revised to reflect the change.
- The project manager must communicate the status of Change Requests with the customer, team members, and other stakeholders. This communication is critical for the project.
- The project manager drives the change management process and ensures that Change Requests are handled in an impartial and expeditious manner.
- Too much change can significantly impact productivity and can lead to project control problems. The project manager determines when the number of changes or the significance of the changes have obscured the direction of the project, and then recommends re-planning the baseline.**
**See J. Davidson Frame, The New
Project Management: Tools for an Age of Rapid Change, Corporate
Reengineering, and Other Business Realities (San Francisco: Jossey-Bass,
1994), pp. 70-73.
TIPS: Guide Your Client through Change Management
We all know that changes will occur
to your projects. A tactic I use is to encourage my clients to budget
for changes up front, so they will have flexibility to change
requirements without the need to seek additional funding.
Stress the importance of adhering to the formal change control process. Talk to your client about changes you have seen on other projects and how they were resolved. A good idea is for you to create a no-cost change request early in the project, and use it to walk your client through the change control process. That way, the process won’t be new to them when a real change is requested.
Finally, if the client does not have the time or money for a requested change in scope, you can offer a “scope exchange.” Identify scope that can be taken out of the project to offset the scope to be added by the change request.
Stress the importance of adhering to the formal change control process. Talk to your client about changes you have seen on other projects and how they were resolved. A good idea is for you to create a no-cost change request early in the project, and use it to walk your client through the change control process. That way, the process won’t be new to them when a real change is requested.
Finally, if the client does not have the time or money for a requested change in scope, you can offer a “scope exchange.” Identify scope that can be taken out of the project to offset the scope to be added by the change request.
Change Management and Your Team
You will need to communicate the
change management process to your project staff. Make sure they know it
is acceptable to say “Let me check” when the client asks them for even a
small change. On big projects, all those little requests can make
scope creep turn into scope gallop and disaster.
Also understand how change requests can affect your team’s performance. When they hear about an important change request, they will lose focus on their work or even stop doing it until the decision about the change is made. So keep your team informed about the status of change requests, and watch out for a letdown in performance.
Closing the Project
A good project closeout ensures that deliverable criteria have been met, documentation is complete, assets are returned, and staff members are released. Project closeout is planned from the beginning of the project and is included in the baseline plans. The baseline includes crisp completion criteria for each deliverable, followed by sponsor signoff as each deliverable is accepted. Also, issues should be resolved as they arise so that they do not accumulate until the end of the project.
If the project manager performs closeout activities throughout the project, few unfinished details will remain at the end of the project
The project closeout step is an important part of the project and should be planned from the beginning of the project. The baseline project plans should also include the closeout activities.
Project managers should start closing out the project from the day that it starts. The completion criteria for each deliverable should be defined in a realistic, measurable way so that the project manager and the sponsor will objectively know when each deliverable is complete. As each deliverable or phase meets its completion criteria, the project manager documents the sponsor's acceptance and formally closes the project. Also, the project manager resolves any project issues as they arise, so that at the end of the project, few deliverables and few unfinished details remain. Following this practice ensures that the project closeout phase runs smoothly and quickly.
Projects can be closed for any of the following reasons:
Cause, default, or breach of contract : One of the parties in the agreement has failed to meet its contractual obligations.
Mutual agreement : Both parties agree to cancel the project by
using a documented procedure so that neither party can claim later that
an agreement was breached.
Project completion : This is the desired outcome. The project sponsor agrees that all terms have been satisfied and the work is complete.
The same closeout procedures are used in all of these situations.
The Project Manager's Responsibilities for Closing a Project
The project manager is responsible for ensuring that the following closeout activities are performed:
Release staff :
The project manager develops the staff release plan for an orderly
closure for team members who have finished their work and then optimizes
the reconfiguration of the remaining project team. The team members
are released as their final deliverables are completed. Releasing staff
includes the following activities:
Release subcontractors :
This step is similar to the releasing staff activity, but it applies to
the orderly closure of the supplier agreement. When releasing a
subcontractor, the project manager verifies that all the terms of the
agreement are fulfilled, including future access to subcontractor
expertise. The project manager develops a subcontractor release plan
that includes the same items as the staff release plan with the
following additional activities:
Manage the end of the project :
This activity is begun when all deliverables in the baseline agreement
have been completed and formally accepted by the sponsor. Attention to
fulfilling the deliverables in the agreement significantly influences
customer satisfaction. The project manager is responsible to ensure the
following activities:
TIPS: Why It Is Important to Close the Project
If your project is not closed properly, significant legal, warranty, asset management, and financial implications to the company can result. Closing your project is the final step in what everyone hopes has been a successful project.
Managing Teams
Understanding personalities and team dynamics enables project managers to manage teams more effectively. The project manager is responsible for establishing an effective project team, which may include both virtual and global teams.
Concept:
Also understand how change requests can affect your team’s performance. When they hear about an important change request, they will lose focus on their work or even stop doing it until the decision about the change is made. So keep your team informed about the status of change requests, and watch out for a letdown in performance.
Closing the Project
A good project closeout ensures that deliverable criteria have been met, documentation is complete, assets are returned, and staff members are released. Project closeout is planned from the beginning of the project and is included in the baseline plans. The baseline includes crisp completion criteria for each deliverable, followed by sponsor signoff as each deliverable is accepted. Also, issues should be resolved as they arise so that they do not accumulate until the end of the project.
If the project manager performs closeout activities throughout the project, few unfinished details will remain at the end of the project
The project closeout step is an important part of the project and should be planned from the beginning of the project. The baseline project plans should also include the closeout activities.
Project managers should start closing out the project from the day that it starts. The completion criteria for each deliverable should be defined in a realistic, measurable way so that the project manager and the sponsor will objectively know when each deliverable is complete. As each deliverable or phase meets its completion criteria, the project manager documents the sponsor's acceptance and formally closes the project. Also, the project manager resolves any project issues as they arise, so that at the end of the project, few deliverables and few unfinished details remain. Following this practice ensures that the project closeout phase runs smoothly and quickly.
Projects can be closed for any of the following reasons:
The same closeout procedures are used in all of these situations.
The Project Manager's Responsibilities for Closing a Project
The project manager is responsible for ensuring that the following closeout activities are performed:
- Tracking the progress of remaining work and release team members after they are no longer occupied.
- As staff members are released, reassigning the remaining work to other team members. The project manager should try to minimize the impact of losing team expertise by ensuring knowledge transfer throughout the project.
- Collecting working documents and office materiel used by the departing team members. The project manager ensures that any reusable intellectual capital has been submitted to the appropriate repositories.
- Collecting other assets allocated to the departing team members, such as PCs and telephones, as appropriate.
- Performing end-of-project interviews to debrief the departing team members.
- Providing performance and professional development feedback to team member's management.
- Deleting the access rights to all databases, files, and applications, and collecting security badges, as needed.
- Organizing a team celebration at the end of the project to thank the team for their help.
- Verifying that agreement terms are fulfilled
- Recovering the technical environment from the subcontractor
- Terminating the supplier agreement
- Preparing the supplier evaluation report for Procurement
- Retaining any needed intellectual capital by debriefing the staff and collecting documentation
- Formally releasing the subcontractor
- Verifying that the scope of the agreement has been met. This includes accepting all deliverables ensuring that contractual obligations are fulfilled, verifying that transition requirements have been completed, and verifying that post-delivery commitments are satisfied, such as readiness to fulfill warranty and support obligations.
- Reconciling the project's financial statements and invoices.
- Reconciling the asset inventory used in the project. This includes identifying the technical environment elements that should be released, retaining what belongs to the company, and returning what belongs to the sponsor. When releasing assets, transfer the warranty and maintenance support and licenses as well.
- Retaining intellectual capital by retaining project management records, files, and software produced in the project. This activity includes determining if any of the intellectual capital should be legally protected by filing a Certificate of Originality (COO), copyright, patent, or document of ownership.
- Capturing lessons learned by gathering and evaluating feedback from sponsor and project team members and subcontractors. The project manager also publishes suggestions for improvement and ensures that actions related to patenting of assets have been completed. Lessons learned should include methods and work products and should identify intellectual capital materials and other reusable materials. This information should be forwarded to the intellectual capital focal point so that future projects can benefit from this experience.
- Terminating the sponsor's agreement by performing the administrative functions to formally close the agreement with the sponsor's signoff.
- Obtaining the sponsor satisfaction feedback in accordance with the delivery organization's practices.
TIPS: Why It Is Important to Close the Project
If your project is not closed properly, significant legal, warranty, asset management, and financial implications to the company can result. Closing your project is the final step in what everyone hopes has been a successful project.
Managing Teams
Understanding personalities and team dynamics enables project managers to manage teams more effectively. The project manager is responsible for establishing an effective project team, which may include both virtual and global teams.
Concept:
Personality Traits
Research shows that there are patterns in most people's personalities, behavior, and how they interact within a team. These traits can be analyzed to predict and improve your project team members' performance. This section discusses the most widely accepted analysis tools and theories:
- Stages of Team Development
- Tools to understand three key behavior patterns
Leadership versus Management
Both leadership and management
skills are needed to be an effective project manager. Some key
differences between these traits are:
- Leaders recognize the need for administration, but they look for ways to innovate for more efficiency. Managers might focus too much on established procedures.
- Leaders motivate team members, develop their talents, and gain their commitment. Managers tend to use resources as they are to get the project done.
- Leaders inspire trust and commitment in their project teams to accomplish goals. Managers exert control to get things done, using position, subject matter knowledge, and authority.
- Leaders tend to look at things from a long-term perspective, ensuring that today’s actions do not cause problems down the road. Managers tend to have a short-term perspective.
- Leaders ask, Why are we doing this? Is this best for the successful outcome of the project? Managers ask, When can you have it done? How will you get it done?
- Leaders are not afraid to challenge the status quo. Managers follow the process.
Project managers who can only manage or
only lead will be less successful. Project managers need a balance of
both managing and leading traits.
Leaders develop talent and capitalize on
the contributions of various team members. Leaders also observe and
provide guidance and encouragement. Leaders are coaches who challenge
others to higher standards and greater achievement. They motivate and
inspire people, and they energize them to overcome political,
bureaucratic, and other barriers. Leaders behave in the following ways:
- Innovate and take risks.
- Develop.
- Inspire trust.
- Have a long-range perspective.
- Ask why.
- Challenge.
- Ask what are you capable of doing in the future.
- Look for potential.
- See people as dynamic and evolving resources.
- Coach.
Manager traits are needed, too. Managers
must administer the day-to-day project by organizing, tracking
progress, and resolving issues. Controlling, planning, staffing, and
monitoring are key to project success. Managers behave in the following
ways:
- Administer.
- Maintain and use.
- Control.
- Use a short-range perspective.
- Ask how and when.
- Maintain the status quo.
- Ask what can you do right now.
- Look for results.
- See people as static and fixed resources.
Team Development
A team is a small number of people
with complementary skills who have a common purpose and mutual
accountability. Types of teams include task forces, development teams,
delivery teams, sales teams, and management teams.* Research indicates
the following conclusions about teams:
*Jon R. Katzenback and Douglas K. Smith,The Wisdom of Teams: Creating the High-Performance Organization (Boston: Harvard Business School Press, 1999), pp. 2-4, 45.
Stages of Team Development
As a team matures, members gradually learn how they fit into the group and cope with the group's pressures. Teams tend to develop this learning in relatively predictable stages. The Tuckman model defines five stages of team development.
There is no set time period for any of the stages. Although the graphic shows the typical progression through the stages, some teams might become stuck in Stage 1 and never progress. Other teams might quickly progress to the Performing stage, then return to an earlier stage in response to a problem or issue. During this project life cycle, team members might progress through the stages at different rates. The team as a whole might be at one stage, but some members might be at other stages.
Forming :
In this stage, individuals begin to learn about the characteristics of
the team and cautiously explore the boundaries of acceptable group
behavior. Team members might feel excitement, anticipation, optimism,
suspicion, fear, anxiety, or pride of team membership. Generally, the
team is excited about this new opportunity and enjoys an initial period
of high morale. The team has low productivity and accomplishes little
during the Forming stage because they are becoming accustomed to new
processes, personalities, and procedures. The following behaviors of
team member might be included in this stage:
Storming :
As team members start to realize the amount of work that lies ahead,
they might begin to panic. Team member feelings might include resisting
the project and questioning the project's chance of success. These
feelings decrease the team's energy. In the Storming stage, team
members begin to understand each other's strengths and weaknesses. As
team members realize the project is more difficult than initially
imagined, they might display the following behaviors:
Norming :
During this stage, members resolve competing goals, loyalties, and
responsibilities. They accept the team, team ground rules, their roles,
and the individuality of fellow team members. During the Norming
stage, team members often feel reduced conflict, acceptance of team
members, team cohesion, and relief that the project is going to work.
As team members settle their differences, they can now start making
significant progress on the project's goals. The following behaviors of
team member might be included in this stage:
Performing :
By this stage, the team has defined its relationships and
expectations. The team begins performing, solving problems, and
implementing changes. Team members have discovered and accepted each
other's strengths and weaknesses and have learned their roles. In the
Performing stage, the team is an effective, cohesive unit and is at its
peak performance.
The following team member behaviors might be included in this stage:
Adjourning :
In this final stage, the project is being completed and closed down.
Team members might feel a sense of accomplishment, along with the
sadness about ending the project and separating from the team.
Behaviors include joking, missing meetings, and expressing
dissatisfaction.
Morale fluctuates throughout the team development stages. Morale in the Forming stage tends to be high with initial excitement. Then in the Storming stage, morale tends to drop as team members realize the difficulty of the tasks ahead. Morale increases again in the Norming and Performing stages as the team makes significant progress toward the project goals.
In the Adjourning stage, morale might be mixed with feelings of accomplishment and uneasiness about project closure. Project managers need to recognize the team development stages to help resolve the typical problems associated with a new team.
Behaviors on Teams
Three general behavior patterns are demonstrated by team members. Teams perform better when they are able to balance these behaviors:
Task-Oriented Behaviors
Task-oriented behaviors focus on the tasks to get the project completed and to keep it under control. These are examples of task-oriented behaviors:
Maintenance-Oriented Behaviors
Maintenance-oriented behaviors focus on the social needs of the team. A balance of task-oriented and maintenance-oriented behaviors is needed to have a well-adjusted, productive, and happy team. The project manager should demonstrate the social conscience for the team. However, other team members might be better suited to this role and perform it unconsciously.
These are examples of maintenance-oriented behaviors:
Self-Oriented Behaviors
Self-oriented behaviors focus on individual team members. These behaviors are directed toward satisfying an individual's own psychological needs of identity, power, control, and influence. Self-oriented behaviors are displayed by individual team members, sometimes at the expense of the rest of the team. Self-oriented behaviors might require corrective actions to channel them for the benefit of the team or to change the behavior so that it will not disrupt the team. These are examples of self-oriented behaviors:
Guidelines for General Team Leadership
The following guidelines are for leading effective teams:
Managing a Geographically Dispersed Team
In conventional office settings, a face-to-face meeting can resolve most misunderstandings. However, dispersed virtual teams might never have a face-to-face meeting. Technology provides the virtual team members with tools to communicate, including video teleconferencing, which should be exploited when possible. The project manager should also promote more communication, monitor team dynamics, and quickly address any relationship issues. The project manager should provide the tools and training to facilitate virtual teams and conduct periodic face-to-face meetings when possible.
Geographic and cultural diversity makes teaming difficult, but it can add a richness to the team and enhance the final product. Recognize differences, such as culture and customs, and then leverage those aspects to build a more cohesive team. When you are managing a geographically dispersed team, be aware of these factors:
The purpose of Team Charter is to set the ground rules for the operation of the project team. The Team Charter provides guidelines for administrative activities, the team's mission, and ways to resolve conflict and to escalate issues. The Team Charter becomes especially important when a team is formed from a mixture of organizations or geographic locations. If the Team Charter is prepared before the team is formed, the project team members should review and refine it. This promotes team buy-in to the Team Charter. New team members who join the project after the review should be expected to accept the existing Team Charter. Team Charters should not be confused with Project Charters, which define the project's objective, resources, assumptions, and constraints. It is the project manager's responsibility to document the following requirements for effective team operations:
Expectations of team members:
Rules of engagement:
Administrative procedures:
TIPS: Plan for Staff Turnover
Cost and schedule overruns can occur because of unplanned staff turnover. Ensure that you have a succession plan in place for key project team members in case they need to leave the project. The plan should identify possible replacements, and the manner in which the transition of responsibilities will take place. Another idea is to cross-train existing team members so they can temporarily take over until a replacement is found.
TIPS: Communication Management Plan is Key to Success
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 ensures that the stakeholders receive the documentation and communication they need, and answers their questions.
[Disclaimer: The information available in this site is purely informational and there is no obligations from the author and the readers of this site. The use of any trademark and copyrighted material is not intended to infringe copyright. This blog is intended to be used under a policy of personal and non-commercial use.]
- Teams produce significant improvements in organizations.
- When surveyed, about 6 of 10 full-time employees prefer working as part of a team.
- Among employees who belong to a team, 18% belong to cross-functional teams.
*Jon R. Katzenback and Douglas K. Smith,
Stages of Team Development
As a team matures, members gradually learn how they fit into the group and cope with the group's pressures. Teams tend to develop this learning in relatively predictable stages. The Tuckman model defines five stages of team development.
There is no set time period for any of the stages. Although the graphic shows the typical progression through the stages, some teams might become stuck in Stage 1 and never progress. Other teams might quickly progress to the Performing stage, then return to an earlier stage in response to a problem or issue. During this project life cycle, team members might progress through the stages at different rates. The team as a whole might be at one stage, but some members might be at other stages.
- Attempts to define the task and decide how it will be accomplished
- Attempts to determine acceptable group behavior and how to deal with group problems
- Decisions on information that needs to be gathered
- Lofty, abstract discussions of concepts and issues
- Discussion of problems and barriers to the project -- some that are relevant to the project and some that are not
- Complaining about the team organization
- Becomes testy or blameful
- Resists collaboration
- Argues about what the real issues are and the actions the team should take
- Becomes defensive and competitive
- Chooses sides
- Questions the wisdom of those who selected the project and appointed the other members of the team
- States concerns about excessive work and unrealistic goals
- Attempts to achieve harmony by avoiding conflict
- Exhibits friendliness toward other team members
- Develops a common spirit and goals
- Establishes and maintains team ground rules and boundaries
- Shows a new ability to express criticism constructively
The following team member behaviors might be included in this stage:
- Implements constructive self-change
- Prevents and quickly resolves problems
- Shows a close attachment within the team
Morale fluctuates throughout the team development stages. Morale in the Forming stage tends to be high with initial excitement. Then in the Storming stage, morale tends to drop as team members realize the difficulty of the tasks ahead. Morale increases again in the Norming and Performing stages as the team makes significant progress toward the project goals.
In the Adjourning stage, morale might be mixed with feelings of accomplishment and uneasiness about project closure. Project managers need to recognize the team development stages to help resolve the typical problems associated with a new team.
Behaviors on Teams
Three general behavior patterns are demonstrated by team members. Teams perform better when they are able to balance these behaviors:
- Task-oriented behaviors focus on what a team must do to finish the job.
- Maintenance-oriented behaviors focus on the social needs of the team.
- Self-oriented behaviors are displayed by individual team members.
Task-oriented behaviors focus on the tasks to get the project completed and to keep it under control. These are examples of task-oriented behaviors:
- Initiating: Defining the team's mission, proposing tasks or goals, and suggesting methods or strategies for proceeding
- Giving information or opinions: Providing relevant information, facts, data, ideas, and opinions
- Clarifying and elaborating: Giving examples, restating ideas in new ways, interpreting ideas and suggestions
- Summarizing: Combining ideas into cohesive statements and drawing conclusions
- Consensus testing: Polling the team to determine how close team members' positions are to each other
- Coordinating: Keeping records, organizing and providing structure, and planning future meetings
Maintenance-oriented behaviors focus on the social needs of the team. A balance of task-oriented and maintenance-oriented behaviors is needed to have a well-adjusted, productive, and happy team. The project manager should demonstrate the social conscience for the team. However, other team members might be better suited to this role and perform it unconsciously.
These are examples of maintenance-oriented behaviors:
- Encouraging: Welcoming others' ideas and opinions, being accepting of and responsive to others' perspectives, and giving others an opportunity to contribute
- Harmonizing: Reducing tension by emphasizing points of agreement and reconciling differences of opinion
- Expressing team feelings: Sensing mood of team and reflecting it back for discussion, sharing own feelings about group processes
- Compromising: Giving in or giving up positions for the sake of harmony, admitting mistakes or errors, exercising personal discipline in response to conflict
- Gatekeeping: Facilitating communication and participation by all team members
- Setting standards and norms: Establishing mutually acceptable ways of interacting within the team setting
Self-Oriented Behaviors
Self-oriented behaviors focus on individual team members. These behaviors are directed toward satisfying an individual's own psychological needs of identity, power, control, and influence. Self-oriented behaviors are displayed by individual team members, sometimes at the expense of the rest of the team. Self-oriented behaviors might require corrective actions to channel them for the benefit of the team or to change the behavior so that it will not disrupt the team. These are examples of self-oriented behaviors:
- Blocking: Attempting to get own way regardless of others
- Digressing: Not staying focused on the topic
- Recognition seeking: Asserting personal dominance
- Clowning: Joking or making fun
- Withdrawing: Psychologically leaving the group
- Sniping: Resisting authority
Guidelines for General Team Leadership
The following guidelines are for leading effective teams:
- Develop a team charter.
- Communicate the project status to the organization.
- Support the team members within their functional units.
- Keep the team focused on goals by repeating them often.
- Show your ability to solve problems.
- Guide and coach the team members.
- Treat all stakeholders ethically.
- Make decisions without unnecessary delays.
- Build a supportive atmosphere where team members can and want to work together.
- Eliminate unrest and unproductive conflict.
- Identify ways to motivate each team member.
- Foster trust and respect among the team members.
- Facilitate free and open communication.
- Orient new team members and quickly get them working efficiently.
- Resolve conflict:
- Understand that conflict is normal and can be productive.
- Focus on the problem, not on the people.
- Solicit input from team members who are most directly involved.
- Resolve the conflict with a win-win or compromise solution whenever possible.
Managing a Geographically Dispersed Team
In conventional office settings, a face-to-face meeting can resolve most misunderstandings. However, dispersed virtual teams might never have a face-to-face meeting. Technology provides the virtual team members with tools to communicate, including video teleconferencing, which should be exploited when possible. The project manager should also promote more communication, monitor team dynamics, and quickly address any relationship issues. The project manager should provide the tools and training to facilitate virtual teams and conduct periodic face-to-face meetings when possible.
Geographic and cultural diversity makes teaming difficult, but it can add a richness to the team and enhance the final product. Recognize differences, such as culture and customs, and then leverage those aspects to build a more cohesive team. When you are managing a geographically dispersed team, be aware of these factors:
- International and country-specific legal requirements
- Applicability of federal government and local laws
- Local cultures and values
- Local customs, including holidays
- Local politics
- Translations and multilingual support
- Labor laws and expatriate employment rules
- Time zones
The purpose of Team Charter is to set the ground rules for the operation of the project team. The Team Charter provides guidelines for administrative activities, the team's mission, and ways to resolve conflict and to escalate issues. The Team Charter becomes especially important when a team is formed from a mixture of organizations or geographic locations. If the Team Charter is prepared before the team is formed, the project team members should review and refine it. This promotes team buy-in to the Team Charter. New team members who join the project after the review should be expected to accept the existing Team Charter. Team Charters should not be confused with Project Charters, which define the project's objective, resources, assumptions, and constraints. It is the project manager's responsibility to document the following requirements for effective team operations:
Expectations of team members:
- When forming a team, it is absolutely essential that expectations be set among team members.
- Behaviors, timeliness, respect, commitment, and openness represent the greatest source of conflict when forming the team. If team members are aware of expectations in these areas, conflicts will be fewer and less intense.
Rules of engagement:
- Meeting protocols
- Making decisions
- Supporting agreements, when they have been made
Administrative procedures:
- Communication management
- Document control
- Escalation procedure
- Work hours, including overtime
TIPS: Plan for Staff Turnover
Cost and schedule overruns can occur because of unplanned staff turnover. Ensure that you have a succession plan in place for key project team members in case they need to leave the project. The plan should identify possible replacements, and the manner in which the transition of responsibilities will take place. Another idea is to cross-train existing team members so they can temporarily take over until a replacement is found.
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 ensures that the stakeholders receive the documentation and communication they need, and answers their questions.
[Disclaimer: The information available in this site is purely informational and there is no obligations from the author and the readers of this site. The use of any trademark and copyrighted material is not intended to infringe copyright. This blog is intended to be used under a policy of personal and non-commercial use.]
No comments:
Post a Comment