pmdocuments Sat, 10 Sep 2016 10:17:00 +0000 en-US hourly 1 pmdocuments 32 32 How to Develop a Rough Order of Magnitude Estimate (ROM Estimate) Wed, 03 Aug 2016 19:44:45 +0000 A Rough Order of Magnitude Estimate (ROM estimate) is an estimation of a project’s level of effort and cost to complete. A ROM estimate takes place very early in a project’s life cycle — during the project selection and approval period and prior to project initiation in most cases. The main purpose of the ROM estimate is to provide decision-makers with the information necessary to make a decision on whether it makes sense to move forward with the project based on the estimated level of effort, in terms of completion time and cost.

Developing a ROM estimate is as much a skill as it is an art. First and foremost, subject matter experts should be involved in level of effort estimations. Second, when developing a ROM, it is important to understand that the estimate is a “Rough Order of Magnitude” estimate that will have an accuracy of about plus or minus 50%. Depending on the source, the variance can be as much as 100%. A variance of -25% to +75% is also common for ROM estimates. The point is to provide a “ballpark” estimate using the information available at the time.

A ROM estimate’s variance is rather large, but it should not dissuade you from making an attempt. Remember that some information is better than no information. Also remember that the estimate is based on the information available at the time of developing the ROM estimate. As the project moves forward, expect to further improve the estimate, when more information is obtained and requirements are further refined during the initiation and planning phases of the project (PMBOK students, do you recall the term progressive elaboration?)

The following information provides a comparison of the three general kinds of estimates as the project makes its way through the life cycle.

  1. ROM Estimate (Variance of -50% to +50%, or -25% to +75% depending on preference)
    • A “ballpark” estimate used to provide a starting estimate to move forward
    • A top-down estimation approach
    • Use of previous expert knowledge and experience
    • Not a great deal of time is spent to develop the ROM estimate
  2. Budget Estimate (Variance of -10% to +25%)
    • Also a top down estimation approach
    • Use of analogous estimation techniques helps provide a slightly more accurate estimate than the ROM estimate (e.g., referencing previous similar types of projects for effort)
  3. Definitive Estimate (Variance of -5% to +10%)
    • A bottom-up estimation technique that requires a decomposition of work and its level of effort that is summed up to develop a more accurate estimate
    • Generally performed during the planning phase and maintained through the remainder of the project
    • This is the most time-consuming estimation effort of the three listed

When developing a ROM estimate, it is best to try estimating in buckets of time and cost. Providing categories may help estimators who otherwise would not be able to provide one number due to the limited amount of information available at the onset of a project. The example below provides categories of “Low”, “Medium”, and “High” levels of effort. Using such a scale may be easier than trying to pull a number out of a hat. It also sets the expectation on both sides — project team and client — that the ROM estimate has a large variance and should be recognized as just an initial ROM.

  1. Low Effort
    • Hours: 40 to 80 hours to complete
    • Cost: $1000 to $5000 dollars
    • Duration: 1 to 4 weeks
    • Number of Resources: 1 to 3 Resources
  2. Medium Effort
    • Hours: 80 to 480 hours to complete
    • Cost: $10,000 to $50,000 dollars
    • Duration: 2 to 6 months
    • Number of Resources: 4 to 10 Resources
  3. High Effort
    • Hours: 480 to 2080 hours to complete
    • Cost: $100,000 to $500,000 dollars
    • Duration: 6 to 12 months
    • Number of Resources: 11 to 20 Resources

Using buckets, or categories like the ones listed above, decompose the work from top down to a level of detail that makes sense given the amount of information available. Assuming that the project is in the very early stages, and stakeholder needs and requirements are at a high level, it is safe to assume that the breakdown of work will not be significantly detailed. The point is not to develop a full-blown WBS here. The point is simply to compartmentalize the work into a set of activities that make sense and that can be measured. For example, developing a web application, the work list might only be a few items like so:

  1. Develop Requirements
  2. Develop the Database Schema
  3. Develop the Application
  4. Test and Deploy the Application
  5. Project Management Activities (Don’t forget to include PM activities. The take time and resources)

Apply a category of effort to each piece of work to come to a ROM estimate. That’s it in a nutshell!

There is a great deal more to know about cost estimating and cost estimating techniques (e.g., Applying learning curves, complexity factors and risk factors; PERT time estimation; Software estimation techniques such as function point analysis technique and COCOMO — But this is a good primer, at least, on ROM estimation. The related links, below, offer additional tips on cost estimating. Also, refer to the Society of Cost Estimating and Analysis (, which is a thought leader in this arena. Expect lots more to come on cost estimation!

Would you like to share additional thoughts or information on ROM cost estimation? Add them to the Comments section below.


Related Links:


Project Charter Document Wed, 25 May 2016 10:16:58 +0000 The Project Charter Document

The Project Charter formally authorizes a project or a project phase.  The Project Charter is best delivered at a project kickoff by the project sponsor so that the Project Manager is given explicit authority by the one sponsor.  A Project Charter can be very powerful if it is given the proper visibility, because it defines the roles and responsibilities within the project and aligns the project to the strategic goals and objectives of the organization.

Specifically, the Project Charter provides the project manager (PM) with the authority to bring the project team together to accomplish the task of completing the project successfully.  It’s true that the PM still faces many resource challenges depending on the structure of the project.  For example, in a highly matrixed project, where the PM does not directly oversee many of the Integrated Project Team (IPT) members, it may be difficult to get the dedicated resources necessary.  However, a properly constructed Project Charter that is communicated to the project stakeholders as early as possible will help clarify the powers of the PM while setting expectations and responsibilities on the other stakeholders.

A Project Charter is generally issued by an entity outside of the project such as an organization, or a portfolio management unit within an organization.  It would not make sense for the project to charter itself.  The project cannot technically be authorized until the Project Charter is completed and authorized.

According to the Project Management Body of Knowledge (PMBOK), a Project Charter results from one of the following needs, or business requirements:

  • A market demand
  • A business need
  • A customer request
  • A technological advance
  • A legal requirement
  • A social need

I’m sure there are others.  A list is meant to be broken!

Last, but definitely not least, a Project Charter should tie the project to the strategic objectives, in terms of business needs of the organization.  If the project is not meeting a specific targeted business need within the organization, then serious thought should be given as to whether the project should be started. This gets into the topic of return on investment (ROI), which is a topic for another day.

The Project Charter should contain the following information:

  • The purpose or justification for the project through a description of the business needs that the project is going fulfill
  • The high level project description or requirements
  • The assigned Project Manager with a specific stated level of authority
  • The stakeholders, and other key Integrated Project Team (IPT) members
  • The organizations involved in the project and their role
  • The project assumptions and constraints that will impact the project
  • Information about the Enterprise Environmental Factors that may be pertinent to how the project will govern and be governed (This can be anything from government/industry standards to market conditions, risk tolerance, decision-making structures, project management information systems (PMIS) and company culture)
  • Organizational process assets (e.g., standard processes, procedures and tools that the organization uses)
  • The business case justification (Does the ROI make sense?)
  • A Summary budget (Probably based on a Rough Order of Magnitude Estimate at this early stage of the project.)

Download a copy of the Project Charter Template:


Preliminary Project Scope Statement Wed, 25 May 2016 10:06:25 +0000 A Preliminary Project Scope Statement is one of the outputs of the Project Initiation process group. The purpose of the Preliminary Project Scope Statement is to identify the high level project objectives.  The objectives must be clear, actionable and measurable.

Recommended sections for the Preliminary Project Scope Statement include:

1.     Project Description

Explain what the project is, and how it will be accomplished.  Explain the ultimate intended outcome of the project.  This should serve as a brief introduction.  Provide some background about the history of how the project got to this point.

2.     Project Purpose

State the purpose of the project.  Tie the purpose to the organization’s strategic goals and objectives if possible.  Tell the reader why this project is being started and what need it is fulfilling.  Identify if there are any specific mandates, policies or laws that are driving this change.

3.     Project Objectives

Provide clear, actionable and measurable objectives of the project.  The objectives should be clear enough so that the project can be measured against the objectives once completed.  The ultimate success of a project is whether the project achieved its stated objectives.  Take time to clearly document the objectives here.

An example of an objective is:

  • The system/product/service will cut response times in half, thus allowing the organization to process twice as many tickets.

4.     Project Requirements

Identify the high level requirements of the product or service that will be developed.   Remember that this is not a detailed list of system requirements or specifications at this point.  The requirements might be at a level that is sufficient for performing an alternatives analysis to identify vendors and service providers that can meet the requirements.

An example of a requirement is:

  • The system will provide users with the ability to create and maintain a login account and profile online.

If you have elicited enough requirements where it makes sense to group the requirements by category, then feel free to display the requirements by category.  Generally, there are two types of requirements: functional and non-functional.  Non-functional requirements are generally broken into groups like security, usability, quality, scalability, privacy, maintainability, etc.

5.     Project Assumptions

Assumptions are conditions at the start of the project that must be considered.  For example, when developing the new software system that is going to take 3 years to fully complete, an assumption could be that the project budget is approved each year for three years so that the project scope is not impacted.

6.     Project Constraints

Constraints are situations or events on the ground that must be considered and accounted, for which the project has no control over.  For example, a constraint can be a hard deadline or completion date.  Other constraints could be resources, tools or hardware — so that if the project has no budget for additional servers, then the project must find a way to develop the new system using the hardware already in place.  This could mean juggling servers to fit specific development environment needs while ensuring that the production environment stays up.

7.     Project Boundaries

If the product or system boundary is known, describe it here.  For example, if a system requires access to multiple external systems (e.g., a system of systems), then it might make sense to break the scope of work into multiple phases so that the scope of the first phase of development would be to only develop the core functionality.  A later phase would integrate the remaining functions.  In this scenario, you essentially could have two projects.  Therefore, clearly defining the project boundaries helps set the scope of work that is to be accomplished.

An example of a system boundary concept is:

  • The online store will integrate with the shopping cart and credit card purchasing modules for the initial release.  The second release will contain social media integration modules.

Don’t be afraid to use architecture diagrams here if it helps visually clarify a system boundary.  The figure below is one of a multitude of types of system diagrams.

System Boundary
Preliminary Project Scope Statement – System Boundary Image

8.     Project Risks

State the known risks.  These risks are generally at a high level since not much is known about the details of the project yet.  If a Benefit-Cost Analysis was performed, then risks identified during the Benefit Cost Analysis should be placed here.  For example, if the project is going to span 5 years and touch multiple third-party systems, then integration and technology change would be risks to consider here. (For examples on how to write a risk statement, visit http://pmdocuments/category/risk-management/)

9.     Project Deliverables

Identify the products and services that the project will deliver.  The intent of this section is to list the product or system deliverables (e.g., An online shopping site), and not the project management deliverables (e.g., Requirements Management Plan)

An example of a product deliverable is:

  • An online store with a shopping cart and credit card purchasing capability.

10.Project Milestones

Identify the project milestones.

Milestone Date Milestone Name Milestone   Description
[Jan 1] System   Requirements Complete System   requirements version 1.0 are approved and baselined so that the project can   begin design and development.
[June 1] Development   Complete Software   development is complete and ready for integration testing
[Dec 1] Deployed   to Production System   passes integration and end-user acceptance testing and is deployed to   production


11.Project High Level Work Breakdown Structure (WBS)

If you have decomposed the high level work that needs to be done, then provide the high level work breakdown structure (WBS) here.  A high level WBS is sometimes referred to as a Rough Order of Magnitude WBS, or ROM WBS.  (For more information on WBS development, visit

12.Rough Order of Magnitude (ROM) Estimate

Provide ROM estimate information here.  If the work has been decomposed and a ROM estimate calculated, then provide the information here. (For more information on ROM estimate development, visit

How to Create a Work Breakdown Structure (WBS) Mon, 23 May 2016 20:47:59 +0000 According to the Project Management Body of Knowledge (PMBOK), creating a WBS is one of the Scope Management knowledge area processes that takes place during the Planning process group (See for the table that displays the PMBOK processes mapped to knowledge area and process group.

Creating a Work Breakdown Structure (WBS) can seem simple conceptually, but there are factors to consider when applying it practically.  However, before jumping into the steps to create a WBS, it is important to understand the need for a WBS.

What is a Work Breakdown Structure?

A WBS is defined by the PMBOK as “a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and created the required deliverables”.   A WBS does not depict time or order of execution.  Rather, its a breakdown of all the work to be done for a project.

A WBS can be organized are functionally, or by phase as indicated in the example below:

Phase-Based Work Breakdown Structure
Phase-Based Work Breakdown Structure


Although the above figure is a graphical example, a WBS can be developed in other formats as well.  In fact, on larger projects, Microsoft Excel or Microsoft Project are better tools for large WBS structures that contain hundreds, or thousands, of lines.

A WBS contains 4 levels as indicated on the above figure (for more information on the construct of a WBS, visit the Wikipedia site as well:   All the work contained in the child elements of a WBS component must equal the complete work to be completed for the parent element.  Note that the work package is the lowest level of decomposition. This is the lowest level WBS component and is called a work package.  This level is considered to be a manageable component of work, which can be scheduled, cost estimated, monitored and controlled.  Generally, a work package should not contain less than 80 hours of work.  There is lots more information on the internet about the WBS levels 1 to 4.  We will not focus on this.  The best resource on the details of each WBS level can be found in the PMBOK.

The main goal of this post is to:

  • Explain the significance of a WBS
  • Provide information on how to facilitate a WBS decomposition exercise
  • provide supporting WBS tools and templates

Why is a Work Breakdown Structure Important?

A WBS is one of the most critical components of a successful project because it forces the project team to carefully consider all the pieces of a project.  Specifically on large projects, it is practically impossible for one person to consider all the work necessary to complete the project.  If the project team does not take the time to decompose the work and consider all the work components, then it is safe to assume that the project team has not performed due dilegence to ensure that all the work has been identified.

On many projects, the WBS development exercise is not performed.  Rather, the project jumps into developing a project schedule.  All too often, the project seems to be progressing smoothly only to realize, later, that a key activity or dependency is missing from the project schedule because it was not considered during the schedule development.  And it was not considered during schedule development because the WBS work decomposition was not performed to try to identify all the work necessary to deliver the product or service.  Or the project schedule underestimated the level of effort for an activity, thus causing delays and potential cost overruns.  Again, the WBS exercise could help with time estimation and sequencing of activities since all the people involved in performing the work are colocated for a period of time with the one purpose of identifying all the work and providing estimates and dependencies on the work.

The WBS exercise of decomposing the work as a team is also a team-building effort.  It implicately creates a sense of agreement as well as accountability among the project team members.

Now, let’s jump into the process of developing a WBS.

How to Facilitate a Work Breakdown Structure Decomposition Exercise?

A successfully developed WBS involves the project team, usually sitting in a half-day to multi-day workshop, to decompose all the work necessary to complete the work.

The main purpose of a WBS excercise is to:

  1. Structure and organize the WBS
  2. Decompose each WBS component into lower level components by identifying all the deliverables and activities necessary to complete the WBS component
  3. Complete a WBS Dictionary Card for each WBS component that contains a detailed explanation of the component, level of effort and other information that could help during project schedule development. (As part of this activity, assigning unique WBS ID numbers to each WBS component is also critical to keep the WBS Cards organized)
  4. Verify that the level of decomposition is sufficient at the Work Package level (the lowest level of the WBS decomposition) to ensure that the work is not too large or small, but manageable.

The steps documented in this section are meant to serve as guidance.  Depending on the size of the project and the culture of the organization, there can be variations of this activity.  However, this should provide guidance on how to use the entire project team to develop the WBS.

1. Organize a WBS Workshop

The WBS workshop should include, at a minimum, the key members of the project team.  Keep in mind that the point of the WBS exercise is to consider all the work required to deliver the final product or service.  So you need the people on the team who are actually doing the work to be there and be actively involved.  Stress the importance of this to the project sponsor and to the project team managers (in a matrixed team, the support of the project team managers is critical since they are allocating resources to the project).

2. Decompose the Work

Decompose the workshop to manageable components of work called work packages, hopefully under the guidance and facilitation of the WBS workshop organizer.  The following tips help facilitate the workshop and make the process of collecting the information simpler.

  • Break up the team into smaller groups that are organized by level 2 of the WBS (In our phase-based WBS, level 2 is the Planning, Implementing, Monitoring & Control and Deployment level.  It is much easier to go into the workshop with a high level WBS structure so that the team doesn not waste valuable workshop time trying to determine the high level WBS structure.
  • Use blank WBS Dictionary cards to collect all the decomposed work elements
    • [downlaod a sample WBS Dictionary Card here.  This sheet has 2 cards, so cut the sheets in half.]
  • Ensure that the teams assign WBS numbers to all the WBS Dictionary Cards they complete.
  • Ensure that there are enough WBS support staff to walk around the room and ensure that the teams understand how to decompose the work using the WBS Dictionary Cards.  Specifically, if the WBS Dictionary Cards are not assigned WBS Numbers, then the cards will be difficult to sort correctly when they are collected later.
  • A good idea it to provide a table workspace for each team so that they can organize their dictionary cards on a table.

3. Compile the WBS Information

Compile the collected WBS Dictionary Cards to create a WBS and supporting WBS Dictionary Document.  The WBS Dictionary Document is essentially an organized collection of the WBS Dictionary Cards.

What Tools Do I Need to Create a Work Breakdown Structure?

There are lots of tools out there to assist with WBS Development.  But the work mentioned here can be performed with Microsoft Office and Excel.   A WBS Dictionary Document Template is available for download below.  Additionally available for download is a WBS spreadsheet that can be used to compile the WBS Dictionary Card information.

[download the WBS Dictionary Excel spreadsheet with auto numbering capability for the WBS – Auto-Numbering and in Excel format (Note: Use indentation to control the numbering of the WBS items)]


[download the WBS Dictionary Document Template here]

As you can see from the reference below, entire books have been written about how to develop a WBS and how to facilitate the team activities.  This post is intended as a primer, but expect more posts on the WBS.

Controlled Change vs Uncontrolled Change Thu, 19 May 2016 19:27:32 +0000 You should always expect that requirements will change from the time you start your project implementation to the time you deploy and through the life of the product or service.
Accept that there are things that you simply will not know until you get into the details of implementation.  And business requirements are in a constant state of flux to stay current with their needs.  In fact, the larger a project and the longer the duration, the greater the number of changes you should expect.
Rule 101 of requirements management is that change is not bad.  Uncontrolled change is bad.  Uncontrolled change means that new requirements are allowed to come into the project with no formal process for analyzing the requirement and accepting / rejecting it.  That’s what requirements management is all about — handling requirements throughout the entire product life cycle.  Requirements management doesn’t stop at the end of design.
So, for example, uncontrolled change would be just letting a new requirement come into the project without having a requirements management process to perform, say, the following things:

  1. Ensure that the new requirement aligns with the goals and objectives of the project
  2. Evaluate how it impacts project cost and schedule
  3. Ensure it is accounted for in testing (this has to do with tracability, not just to goals and objectives but to downstream processes and activities like testing)
  4. Formally accept (or reject or postpone) by a change control board or a body with the authority to accept the new requirement — after assessing the analysis and impact results of the new requirements against the project
  5. Ensuring that resources are available if additional resources are required


For more information look at the scope management section of the Project Management Body of Knowledge (PMBOK). Here are 4 books on this topic, including the PMBOK:

Risk Management and Issue Management Process Primer Thu, 19 May 2016 19:26:47 +0000 Risk Management and Issue Management are related processes that are critical to project and program management success.  For the sake of simplicity, the focus of this article will be on project-based risk and issue management.  Understanding these processes at the project level will provide the foundation to be able to extrapolate these concepts to the program level.

A project risk is anything that has the potential of negatively or positively impacted a project.  Note that a risk does not need to always be a negative impact.  Risks that have a potential to positively impact a project are called opportunities.  For this post the focus will be on negatively impacting risks because identification of negatively impacting risks are generally the priority of projects and the things that keep project managers awake at night.

A risk is a condition that has not occurred yet.  For example, if  a company’s production website is hosted on one server with no on-site or off-site backup or recovery processes in place, then it is evident that there is a risk of a single point of failure.  If the server fails for any reason, then the company’s production web site will be down until they can recover the server or replace it with a new one.

This seems like  simple enough concept, right?  Good.  Now let’s put a bit of construct around the way a risk is identified, measured, mitigated and monitored:

  1. The Risk Management Process:
    1. Risk Identification
    2. Risk Measurement
    3. Risk Mitigation
    4. Risk Monitoring and Review

1.  Risk identification

Generally, there are two acceptable sentence structures for documenting an identified risk — the If-Then statement, and the Condition-Consequence statement.

  1. If-Then Risk Statement Format:  If [event], then [consequence]
    • If  the company’s production web site goes down, then the company will lose internet sales until the server can come back up.
  2. Condition-Consequence Risk Statement: Given [event], there is a risk that [consequence]
    • Given the fact that their production web site is hosted on one server with no documented backup or recovery options readily available, there is a risk that we could lose internet sales if the server goes down.

Both formats of risk documentation are acceptable.  The Project Management Body of Knowledge (PMBOK) prefers the second option.  I happen to prefer the second option as well.  I find that it easier to write a risk statement clearly with the second option.

The risk is logged and managed on a Risk Ledger, which is generally a spreadsheet of risks that are maintained and reviewed periodically.  There are also tools that can support the development and maintenance of a Risk Ledger.  A risk ledger, at a minimum, contains the following fields of information for each risk:

  1. Risk Number – a unique number for the risk – used for identification purposes or for associating the risk to other information as needed
  2. Risk Name – a brief name to quickly recognize the risk
  3. Risk Description – a description of the risk written in risk statement format
  4. Risk Date – the date that the risk was identified
  5. Risk Owner – the person assigned to be responsible for the risk (Risk owner specific responsibilities vary, but generally, the owner is responsible for the risk in some manner)
  6. Risk Trigger – the event that would trigger the risk (In the server example above, it would be “The server crashes”
  7. Risk Mitigation Strategy – a description of the activities that must be put into place to mitigate the risk — thus reducing the probability of the risk from occurring and/or the impact of the risk should it occur (In larger projects, the risk mitigation strategy might require a separate document in order to capture the complete details.)
  8. Risk Contingency Plan – contains information on what needs to take place if the risk is realized (Once the risk is realized, meaning that it comes to fruition, the risk becomes an issue.  An issue is a condition that is currently impacting the project negatively.  Specific activities must kick in to action to resolve the issue.  So in the server example above, the contingency plan would be to install the application on a development server and make the development server temporarily the production server until a new production server is bought and configured.)
  9. Risk Status — open, closed
  10. Notes — Notes from periodic status updates from the risk owner

2.  Risk Measurement

Once the risk has been identified and documented, a risk owner must be assigned.  Generally, a project that has a mature risk management process has a risk group that is responsible for reviewing, analyzing and mitigating risks.  The risk is assigned by the Risk Group Lead.  The person assigned to the risk is the recognized as the Risk Owner.

It is up to the Risk Owner to assess the risk, validate that it truly is a risk and identify a mitigation strategy for the risk.  A mitigation strategy is the plan of action that needs to be put in place to ensure that the risk is not realized.

This risk review team reviews the risk and measures the probability and impact by assigning a probability and impact score — where probability is the likelihood that the risk could be realized, and the impact is the severity of the consequence should the risk be realized.  The risk score is a product of these two scores (Risk Score = Probability x Impact).  For example, let’s assume that the probability score and the impact score values are 1, 2 and 3 for low, medium and high respectively.  If the risk team indicates that the probability that the server might go down medium, but the impact is high, then the Risk Score is 6.

Risk Score = Probability x Impact

All identified risks must be assessed for probability and impact, a risk owner must be assigned to ensure that the risk is mitigated through the project life cycle, and a risk score must be assigned to each risk.  The risk score serves as a measure of the risk’s priority.  The higher the risk score, the higher the priority.

Depending on the project’s risk tolerance (Tolerance levels can be different from project to project, or from organization to organization), a decision must be made to take one of the following actions:

  1. Accept the risk — There may be cases where the risk does not pose enough of a risk (based on risk score, probability or impact).  Therefore the cost of mitigating the risk might be much more than the cost of the risk itself, should it occur.  Or the risk probability might be so low that a calculated risk is taken to accept the risk.
  2. Avoid the risk — For example, if a risk is associated with a specific module or component of code, and the component can be put off for a future release or just de-scoped from the project, then a decision can be made to avoid the risk altogether.
  3. Transfer the risk — Outsource the work so that the responsibility of mitigating the risk becomes the responsibility of another service provider or contractor.
  4. Mitigate the risk — Make a conscious decision to develop a strategy to mitigate the risk to that it is not realized

3.  Risk Mitigation

Should the decision be made to mitigate the risk, the Risk Owner, working with the Risk Group, is responsible for devising a risk mitigation strategy for the assigned risk.  The risk mitigation strategy, or risk mitigation plan is a plan that is put into place to reduce the probability of the risk from taking occurring and reducing the impact, should the risk occur.

Using the previously mentioned example of the single server production environment, a mitigation strategy might be to back up the application server.  Another mitigation strategy could be to have another hot-backup available so that if the primary server fails, the second server could take over.

3.  Risk Monitor and Review

Once a risk mitigation strategy is in place, the risk group must periodically monitor the risk to ensure that the risk is being mitigated.  This can take place through periodic status updates by Risk Owners via meetings or reports.

If the risk is realized, meaning that the risk trigger actually takes place — in this case, the trigger being the fail of the production server — then the risk becomes an issue.  An issue is a condition that is currently having a negative impact on your project.  See the next post for more on Issue Management.

Risk Management is a very broad subject.  For further research, refer to the links below.  There are also many Risk Management certification programs, including one by the Project Management Institute called the PMI-RMP certification (

Please comment below if you have additional comments or feedback.  Also feel free to let me know of additional risk management references, trainings and certification programs.


Related Links:

About the Picture:  A beautiful fall day in October in the Plains, VA

How to Motivate Others as a Project Manager Thu, 19 May 2016 19:25:48 +0000
How to Motivate as a Project Manager

The first topic of motivation is a fitting start.  Motivation is necessary to lead and to succeed — personally and professionally.

As a project manager, motivation is a multi-faceted term.  There is the inner motivation to succeed as the project manager by delivering a product or service as promised (on time, within budget and scope, and delivered at an acceptable level of quality from the client’s perspective — more on this topic later).  There is also the need to motivate your team.  In most projects, the idea that started the project probably did not come from the project manager or the project team.  It was most likely thought of at the stakeholder / client level or even higher.

So, as the project manager, you are responsible for providing motivation to your project team as well as digging deep within yourself to find and maintain the motivation to succeed and deliver.  When doing this, keep a few things in mind:

  1. Understand what your motivation is first — You will have trouble motivating others if you cannot motivate yourself
  2. Be a good listener — You will not be able to gauge the team’s motivation if you do not open up and listen.  (Sometimes silence can be deafening as well!)
  3. Understand the source of each person’s motivation — Motivation means different things to different persons on your team, so the same motivation will not work for everyone
  4. Set goals and create challenges for your team — to help keep them focused, especially during lulls in action
  5. Give people responsibility and let them run with it — Try not to micro-manage the team.  You will find that following this point frees you from having to take care of every detail so you can focus on other challenges.  I recall when I reached this fork in the road in my career.  I had a very talented team member that was very capable and, rather than take on all the responsibility, I passed on some of the responsibility of the project to him, which freed me to take on other value-added initiatives within the project and within the organization.
  6. Communicate what is at stake (if you do not succeed) — this is the “stick” part of “the carrot and the stick”  — but, again, be aware of what motivates your team (see bullet 3)
  7. Be aware of the work environment — is it comfortable and do they have their basic needs met?  Seems simple, but goes a long way
  8. Have a plan and stick to it, yet remain flexible as needed — Nothing drains a team more than not knowing the trajectory of the project, or feeling that the project is flailing.  When this begins to happen, it can turn into major motivation killer for the team.  Set your sails and go!  But be flexible.  Don’t head into a storm just because you’ve charted that direction.
  9. Treat the team once in a while — Bring in donuts or bagels, or have a friday lunch meeting.  Whatever works to motivate the team and break the monotony
  10. Thank others! — People want to feel needed and appreciated

Related Links:


About the Picture:  This photo was taken from a boat on the Occoquan Bay near the Virginia / Maryland border — on a beautiful day in August 2012.

PERT Three Point Estimation Technique Thu, 19 May 2016 19:24:47 +0000 PERT Three Point Estimate Technique

The PERT Three Point Estimate technique is a type of three point estimate.  The only difference is that it applies weighting so that the most-likely estimate is weighted 4 times more than the other two estimates (optimistic and pessimistic). This formula is most valuable in estimating time or cost of activities for projects that are especially unique, such as in research and development where there are many unknowns.  For projects that are similar to previous projects and there is good historical data and expert experience, the formula is less useful because you could use other techniques like analogous estimating (based on previous experience and projects).

Pert Estimate

E = (o + 4m + p) / 6

where E is Estimate; o = optimistic estimate; p = pessimistic estimate; m = most likely estimate

Standard Deviation

SD = (p − o)/6

where SD is Standard Deviation; p = pessimistic estimate; o = optimistic estimate

To produce a PERT three point estimate:

  1. Decompose the project into a list of estimable tasks, i.e. identify tasks for each Work Breakdown Structure (WBS) work package
  2. Estimate the E value and SD for each task.
  3. Calculate the E value for the total project work as E (Project Work) = Σ E (Task)
  4. Calculate the SD value for the total project work as SD (Project Work) = √Σ SD (Task) 2

The E and SD values are then used to convert the project estimates to confidence levels as follows:

  1. Confidence level in E value +/- SD is approximately 68%
  2. Confidence level in E value +/- 1.645 × SD is approximately 90%
  3. Confidence level in E value +/- 2 × SD is approximately 95%
  4. Confidence level in E value +/- 3 × SD is approximately 99.7%
  5. Information Systems typically use the 95% confidence level, i.e. E Value + 1.645 × SD, for all project and task estimates.[2]

PERT Three Point Estimate Example:

For Activity A:

  • o = 4 hours
  • p = 16 hours
  • m = 8 hours

Using the estimates above for Activity A, calculate the Estimate:

  1. E = (4 + 4(8) + 16) / 6
  2. E = 52 / 6
  3. E = 8.7 hours

Using the estimates above for Activity A, calculate the Standard Deviation:

  1. SD = (16 – 4) / 6
  2. SD =  12 / 6
  3. SD = 2 hours

PERT Three Point Estimate Results for Activity A: 

  1. 6.5h – 10.5h hours:            Confidence level in E value +/- SD is approximately 68.2%
  2. 5.4h – 12h:                      Confidence level in E value +/- 1.645 × SD is approximately 90%
  3. 4.7h – 12.7h:                    Confidence level in E value +/- 2 × SD is approximately 95%
  4. 2.7h – 14.7h:                      Confidence level in E value +/- 3 × SD is approximately 99.7%
  5. Information Systems typically use the 90% confidence level, i.e. E Value + 1.645 × SD, for all project and task estimates.

PERT Three Point Estimation References:

PERT Three Point Estimation Tools



8 Tips to Launching and Maintaining a Successful PMO Thu, 19 May 2016 19:24:10 +0000 Setting up a Program Management Office (PMO) is as much an art as it is a skill.  Entire books have been written about standing up a PMO.  In fact, each of the tips discussed here could stand as a chapter on its own.  With this in mind, realize that this is a general primer intended to provide high level guidance and to share some lessons learned from previous PMO startup attempts.

So what are some of the common challenges of establishing a PMO? And why do so many of them fail to perform as expected?  First, it is important to understand the type of PMO that is being established.  It is essential that the role of the PMO is well-defined, and that the role is understood and communicated to everyone in the organization.  Just like any endeavor, to be successful, you have to know why it is being done and you must communicate it.  A poorly defined PMO role can lead to the PMO overextending its reach or failing to meet perform due to a lack of direction.

There are some key points to consider when standing up and maintaining a successful PMO.  Let’s go into the 8 tips for launching and maintaining a successful PMO.

1. Understand the type of PMO that needs to be established

It is true that PMOs have certain common objectives:

  • Maintain a centralized set of processes and ensure that they are adhered to
  • Maintain  a central set of project management (PM) tools and services
  • Centrally track resources for projects
  • Provide support to project managers and senior management on ensuring project control
  • Support the goal of ensuring project quality and strategic alignment
  • Facilitate performance reporting
  • Support portfolio selection
  • Provide centralized acquisition management services
  • Maintain a knowledge repository of processes, templates and lessons learned

However,  it is important to understand that within an organization PMOs can be established to serve a specific purpose.  According to the Program Management Office Handbook, a book put out by the PMO Special Interest Group (PMOSIG) of the Project Management Institute (PMI), there are six types of Programs:

  • Strategic Program – focuses on work to align to with the organization’s strategic goals and objectives
  • Operational Program – focuses on operations within an organization — specifically operational process improvement initiatives to drive operational effectiveness and efficiency
  • Product Program – focuses on a specific product
  • Functional Program – aligns to a specific function of the organization such as service delivery or information technology
  • Enterprise Program – generally high risk programs that span across the organization and impact multiple business units, operations and functions.  They are cross functional and generally intended to deliver changes in direction or focus on positioning for new opportunities for growth.

Each of the above types of Programs could have their own PMO within an organization.  In an organization with multiple types of PMOs, it also makes sense to establish an Enterprise PMO.  The enterprise PMO would establish a central taxonomy and nomenclature, maintain a central repository of processes, templates and documentation, and provide centralized training and mentoring.

2. Determine the PMO’s roles and responsibilities

Within a PMO, the specific roles and responsibilities can vary depending on the level of sponsor support and the stated goals and objectives of the PMO.  A PMO can serve one or more of the following roles:

  • Mentoring and coaching
  • Process methodology definition and maintenance
  • Project monitoring and control
  • Governance support and strategic alignment
  • Value delivery
  • Reporting (Project and Management level)
  • Communication
  • Training
  • Project execution
  • Project selection
  • Acquisition Management and Support
  • Life Cycle enforcement and reviews
  • Budget and resource estimation

Based on the above list of possible responsibilities, this will impact the types of roles and the number of people involved.  Generally, PMOs that provide guidance but do not actually have the responsibility of running projects or programs are not very large — perhaps 3 to 5 members.  Is the PMO responsible for management reporting?  Is the PMO responsible for ensuring that projects are following the defined life cycle?  Is the PMO responsible for promoting effective and efficient operations?  Does the PMO have portfolio decision-making authority?  Or does the PMO support senior management by supplying information to help senior management make portfolio decisions (accepting, maintaining and removing projects from the portfolio based on performance or risk factors, etc.).   All of these considerations will impact the size and structure of the PMO.

3. Obtain senior management backing and support

A key factor in the PMO’s overall success is upper management support.  The sponsor must ensure that the PMO has pubic backing and the authority and direction to move forward.  If the PMO launches as a half-hearted effort to try the latest trend in management techniques, then it does not have a good chance of succeeding.  Only with a clear vision for the PMO, and a sponsor that is willing to communicate the vision, will the PMO be able to reach its full potential.

4. Develop a communication strategy and reach out if needed

Understand the significance of a PMO communication strategy.  PMO communication responsibilities can be two-fold.   The first communication responsibility includes managing and directing communication within the project or program.   Second, the PMO must communicate out to the organization on the PMO’s goals and objectives.  Depending on the level of senior management support, the second point may be critical to the overall success of the PMO.  In an organization where the PMO’s direct level of authority is limited, the PMO might have to reach out to programs, functions and business units to let them know that the PMO is there to support them.   This is common in PMOs that mainly promote process improvement, but don’t generally have the enforcement authority to ensure that all projects follow a consistent process.

5. Focus on providing immediate value

Immediate value is critical, yet sometimes overlooked.  There is no need to try to involve the PMO across all work products from the outset.  It is better to start with one or two projects so that the work is manageable.  This allows the PMO to show value to the organization quickly.   Remember that most PMOs are considered overhead cost (Generally should not be more than 10% of the budget of the project or program).  Since the PMO is not a money-making operation, it must show that it is improving effectiveness and efficiency through solid performance metrics.  By being able to provide and show value, the PMO can gain the confidence of management and the organization and ultimately become a trusted parter to management.

6. Ensure Alignment with the organization strategy

As a PMO, ensuring alignment to the organization’s strategic goals and objectives should be forefront on the PMO’s list of priorities.  PMOs have a responsibility to ensure that the organization’s work is aligned with its strategic objectives.  PMOs must also ensure that they are in tune with the direction of the organization.  For example, if the organization is making a push for a more modular approach to development with iterative release cycles, the PMO needs to ensure that the life cycle reflects this change in direction.

7. Consider Surveys

Yes, consider surveying the organization periodically to gauge the PMO’s perceived value within the organization.  Of course, once a survey is conducted, make sure to respond to the feedback.

8. Provide the right tools

A good PMO provides the organization with a good set of centralized tools to help them manage their work.  It’s as simple as that.  Provide the right tools, templates and documentation to ensure that the work is being performed per the life cycle.  The tools should strive to take out the guess-work for project staff by guiding them through the processes and leaving little to guesswork.  The tools should also provide management with insight into the work being performed.  Additionally the tools should allow the PMO to become the central repository of information regarding project status, resources, schedules and artifacts.

Future posts will touch more on some of these topics.

The following book in the “Links” section, and listed for purchase through Amazon, is a book that I personally used on a project to develop a PMO.  I found the information insightful and practical with real-world challenges and examples of how to deal with them:

Related Links:

Recommended Book:

  • The PMOSIG Program Management Office Handbook — Strategic and Tactical Insights for Improving Results


About the Picture: Watching the birds in the Outer Banks

Project Templates Thu, 19 May 2016 19:23:29 +0000 External Links to Project Templates

Here is a running list of project templates.  This list is organized by free project templates as well as more robust and professional project templates:

Professional Project Templates (recommended)

The advantage of professional project templates is that they offer a consistent design, style and layout.  The consistency helps when writing the documents.  These project templates, also offer help when writing your document by providing canned text and guidance.  If you have the budget and can purshase one of these project templates, it will probably save you time in the long run and provide the consistency you, or your organization is looking for.

  1. Method 123 Seems to be the most professional and comprehensive package — also the most popular.  Follows PMBOK as well.
  2. Project Management Templates — Claims to be The Very Best Professional Project Management Documentation. Every Template & Form Includes Detailed Guides And Examples. Everything A Project Manager Needs To Deliver Successful Outcomes.
  3. PM Toolkit — Set of 49 Project Management Templates. There is an option on the home page to download a dozen of the most popular templates for free
  4. 100+ Document Templates from True Solutions  (Based on PMBOK 5th edition).  They also offer the a CAPM / PMP exam application tool kid — the only one on the market that they are aware of.
  5. Project Management templates provided by CVR/IT Consulting (various packages of documents are available for purchase)  — free to use or download for non-profit or government entities.

Free Project Templates

  1. Free Project Management Templates from
  2. Free Project Management Templates from is a collection of templates from various sources
  3. From the Defense Acquisition University website, there is a collection of Air-Force provided acquisition, planning and reporting document templates
  4. University of California Santa Cruz offers a few project templates
  5. The PM Notebook offers some good and insightful content related to project management an offers free templates and links to other resources

This is an ever-growing list.  If you would like to add additional sources of project templates and tools, please post a reply to this page.  Include the URL of the site and a brief description if possible.  Thank You!