Making Informed Project Management Decisions

Making decisions is part of daily life for any manager or executive. Some decisions may result in a change of strategy in personnel policy or employee training. Other decisions may result in undertaking a project to launch a new product line. A gamble often is associated with important decisions. Newspapers frequently report the names of executives who were rewarded for “making the right decision” and those who were fired for being wrong. More than likely, those who were rewarded had weighed the pros and cons of the situation and had become thoroughly informed before deciding on the venture.

Making informed decisions is the dilemma at the heart of assessing potential project hazards. It plagues the project manager whose sponsor requests that he or she prepare an assessment of potential project hazards for the statement of work.

How does a project manager go about making informed decisions concerning potential external project hazards? By going out and talking to as many people as possible who have knowledge of every conceivable aspect of the project—and by gathering as much input from them as possible.

Armed with this information, the project manager should be able to formulate key questions for the experts who have the answers. For example, if a project involves building a new atomic power plant, a critical question for a politician from the affected district would be, “Will the government become so environmentally concerned during the construction phase of the plant that they might close us down before we can complete it?” A seismologist could be asked, “What is the earthquake possibility on the land where we propose to build?”

Read more »

How Much Effort Should Scope Definition Take?

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

We’ve looked at how you go about communicating scope, now let’s look at the concept of how much effort should go into defining the scope of your project or product development process. This article is based somewhat on text from the book “Customer-Centered Products” by Hooks and Farry.

Scope definition is one of the most critical aspects of project or product management. Without proper scope definition, a project is destined to experience continual scope creep resulting in ongoing timeline and budgeting issues.

When the scope creep happens, the only way around the timeline and budgeting issues will be to introduce many change orders to your customer which will likely decrease their satisfaction level significantly. You’ll still have the timeline issues and the budget issues, but you’ll be able to justify them with the stack of change orders – assuming the customer actually approves all of them rather than flat out canceling the project altogether out of frustration. A much better route is to spend the proper amount of time up front correctly identifying and documenting scope and gaining agreement with the customer on that carefully defined scope. Read more »

Communicating Project Scope

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

The Scope Document

Once the project scope is defined, it must be documented to ensure that everyone assigned to the project will address the right tasks and work toward the same project goals. A formal scope document is essential to keeping a project on track. The order that these scope items are covered and the amount of space devoted to each in this document will depend on the type and size of the project and the number of scope items that need to be covered. On small projects, needs, goals, objectives, and missions will often be the same thing – easily described in a few statements. Distinguishing between these things is not that important, but establishing a flow from less measurable statements of need to more measurable ones truly is important. Read more »

What Goes into a Good Statement of Work

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from one of my favorite PM books – Eric Verzuh’s book entitled “The Portable MBA in Project Management.”

The statement of work (SOW) basically kicks off the project management process and is meant to document the goals and constraints of a project. However, it cannot and certainly should not attempt to document every agreement about the project. There are other project and project management documents for this purpose – requirements, specifications, customer acceptance tests, and also you basic output of agreements and notes from kicking off the project with the customer. The SOW should record the goals and constraints for managing the project. While that can contain a wide range of information, the minimum content listed here gives you an idea of what makes up a good, useable SOW:

• Purpose statement: A clear description of why we are doing this project.
• Scope statement: A description of the major activities of the project in such a way that it will be absolutely clear if extra work is added later on.
• Deliverables: A list of outputs the project will produce, including intermediate deliverables, end deliverables, and deliverables related to project management.
• Cost and schedule estimates: In addition to a budget and a deadline, a description of how flexible the budget is and the rationale behind the deadline.
• Project objectives: The specific, measurable goals of the project.
• Chain of command: An organization chart that spells out who makes decisions and to which superior problems will be reported. It is often a good idea to include the organization chart of the customer, as well.

The SOW is a tool for managing expectations and dealing with change. When disagreements arise after the project has started, they can sometimes be solved by simply reviewing the original SOW. However, it is also true that the original agreements and assumptions may change during the course of a project. In this case, all stakeholders must understand and agree to these changes, and the project manager must write them into the SOW or track them through other project management processes such as change orders. The SOW that remains at the end of the project may be very different from the original document. The amount of this difference is not important; what is important is that everyone has been kept up to date and has agreed to the changes.

Project Management Templates

Over the past several couple of weeks I’ve discussed many project management-related templates and documents that are commonly used. And along the way over the past 10 months there have been a few other templates and documents discussed.

In an attempt to provide a one-stop document to link to all those templates and documents discussed so far, I’m going to pull them all into this article as a list with available links. Hopefully, having the accumulated list available in one place will be helpful to our readers.

Again, not all of these will be links to templates…some will merely be links to documents that have been discussed in greater detail in previous articles.

• Statement of Work
• Project Status Report
• Communication Plan
• Communication Plan
• Risk Management Plan
• Lessons Learned
• Lessons Learned
• Requirements Traceability Matrix
• Market Analysis
• Project Management Methodology
• Quality Management Plan
• Project Request Document
• Project Charter Document
• Business Case Document
• Change Order Request
• Change Order Request
• Resource Request
• Onsite Visit Progress Report
• Procurement Plan
• Lessons Learned Survey
• Disaster Recover Plan

Summary

As discussed in most of these articles, if having the actual template in a Word doc format would be helpful, just let me know and I’ll be happy to send it to you if I have it. In some cases, I may be able to send you an actual example document from a real project allowing you to better see how I’ve populated some of the information with meaningful data. I’ll revise and republish this article as I make more templates and documents on these and similar topics available that I think would be useful to our readers.