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.
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.
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:
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 — http://cost.jsc.nasa.gov/COCOMO.html). 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 (http://www.sceaonline.org/), 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.
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:
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:
Download a copy of the Project Charter Template:
Recommended sections for the Preliminary Project Scope Statement include:
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.
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.
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:
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:
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.
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.
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.
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:
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.
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/)
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:
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|
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 http://www.pmdocuments.com)
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 http://www.pmdocuments.com)
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.
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:
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: http://en.wikipedia.org/wiki/Work_breakdown_structure). 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:
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.
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:
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.
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).
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.
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.]]>
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:]]>
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. Risk identification
Generally, there are two acceptable sentence structures for documenting an identified risk — the If-Then statement, and the Condition-Consequence statement.
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:
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:
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 (http://www.pmi.org/certification/risk-management-professional-rmp.aspx).
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.
About the Picture: A beautiful fall day in October in the Plains, VA]]>
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:
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.]]>
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).
E = (o + 4m + p) / 6
where E is Estimate; o = optimistic estimate; p = pessimistic estimate; m = most likely estimate
SD = (p − o)/6
where SD is Standard Deviation; p = pessimistic estimate; o = optimistic estimate
The E and SD values are then used to convert the project estimates to confidence levels as follows:
For Activity A:
Using the estimates above for Activity A, calculate the Estimate:
Using the estimates above for Activity A, calculate the Standard Deviation:
PERT Three Point Estimate Results for Activity A:
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.
It is true that PMOs have certain common objectives:
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:
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.
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:
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.
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.
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.
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.
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.
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.
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:
About the Picture: Watching the birds in the Outer Banks]]>
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:
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.
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!]]>