Decide Whether Your Estimate Should Include Client Cost and Effort

Client effort includes the time to review and approve deliverables, provide requirements, attend meetings, participate in training, etc. Some companies want to understand the total effort and cost of a project, including both the direct project team and the client resource requirements. In other companies, the project costs only include the direct project team. Whether you include client hours and cost in your estimate is an area you should discuss with your manager and your sponsor. If your project estimate includes client hours and cost, the hours need to be kept separately. Although the combined number provides a better overall estimate, the project manager normally is not responsible for the client resources and so he should not be held accountable for achieving those particular targets.

Be Prepared if Others Think Your Estimate is Too High

After you have prepared your estimate, you may need to defend it if the client thinks that the numbers are too high. You should be able to first defend the estimate by explaining the estimating techniques you used, the process you followed and the assumptions you made. If the client still thinks the numbers are too high, or cannot afford the solution at that cost, there are a few options.

* Determine if the client has any additional information that would allow you to revise your assumptions and perhaps revise the estimate. For instance, if a critical end-date now has some flexibility, perhaps the estimate can be revised based on this new information.
* Determine whether high-level requirements and functionality can be scaled back. In many cases, the original set of features and functions is more of a wish list. After seeing a price tag, it is very possible that the client can live without certain features.
* If you included a high contingency to reflect a high estimating risk, ask the client for more time to gather more detail for the estimate. This may result in there being less uncertainty and risk, and allow you to reflect this as a smaller contingency.
* Restructure the project to only include the detailed analysis phase. After the full analysis is completed, re-estimate the remainder of the project, based on a confirmation of exactly what is being requested. The total effort and cost may or may not be lower, but at least you will have more detailed information to back up your estimate.

Back up Your Estimates with a Full Estimating Packet

The next time you are asked to provide an estimate for a major piece of work, consider presenting a packet of information. This does not have to be a thick document; it is only meant to show the rigor that you went through. You should especially consider this if the work is political or if you think that your estimate will not be accepted. Rather than just providing a final estimate, or an estimate range, provide the following information instead.

* Your understanding of the work that was requested
* The process you used to prepare the estimate
* The estimating technique(s) you used
* The actual estimate of the work effort (and duration and cost, if applicable)
* The detailed estimating information in case the sponsor would like to review. For instance, if you did a Work Breakdown Structure, you can include your detailed work estimates
* The assumptions you made in developing the estimate
* The level of uncertainty in the numbers that is reflected in the contingency or the size of the estimating range (more uncertainty is reflected in a wider range)

This would be a powerful packet of information to return to the requestor. If there were disagreements with your estimate, this would give you the facts to respond. It will also stop many challenges because people will have difficulty disputing your facts. You may get asked to change your estimating assumptions or to try another estimating technique. These are legitimate requests and you can re-estimate based on new criteria. But at least the challenges are in terms of the estimating process, not on whether you did a poor job on the estimate itself.

Communication Management Plan Examples

The following items are examples of the types of communication that could be created as part of an overall Communication Management Plan:

Mandatory

These types of communication are required by your company, your industry or by law. This information is �pushed� (sent directly to) to recipients.

* Project Status Reports
* Regular voicemail updates (of status)
* Status meetings
* Meetings with steering committee
* Regular conference calls and videoconferences with remote stakeholders
* Required reports to shareholders or your Board of Directors
* Government required reports and other information
* Required financial reporting such as budget vs. actuals, budget variances, etc.

Informational

This is information people want to know or that they may need for their jobs. This information is made available for people to read, but requires them to take the initiative, or �pull� the communication.

* Awareness building sessions that people are invited to attend (these are not meant as training � just to build awareness of the project)
* Project deliverables placed in a common repository, directory, website or library that people can access
* Frequently-asked questions

Marketing

These are designed to build buy-in and enthusiasm for the project and the deliverables. This type of communication is �pushed� to the readers.

* Project newsletters with positive marketing spin
* Meeting one-on-one with key stakeholders on an ongoing basis
* Traveling road shows to various locations and departments to explain the project and benefits
* Testimonials from others that describe how the project deliverables provided value
* Contests with simple prizes to build excitement
* Project acronyms and slogans to portray a positive images of the project
* Project countdown-until-live date
* Informal (but purposeful) walking around to initiate discussions about all the good things the project is accomplishing
* Celebrations to bring visibility to the completion of major milestones
* Project memorabilia with project name or image portrayed, such as pins, pencils, Frisbees, cups, T-shirts, etc.
* Publicizing accomplishments

The point of the examples is to show that project communication can take many shapes and forms. For large projects especially, the project team should be creative in determining how, what, to whom, where and how frequently the communication takes place. If the project is controversial, requires culture change or is political, the positive aspects of marketing communication become more and more critical. In these cases, you can also put a proactive plan in place to brand the project with a positive image and feeling.

The Document Life Cycle

It is important for the project manager to recognize the stages that a document must go through from creation to completion. This knowledge allows the project manager to understand the overall status of a document at any given time and helps ensure adequate time is allocated for the completion of the document. For instance, when a team member says they can complete a document in two weeks, are they saying that the document will be ready to circulate in two weeks or that the document will be completed and totally approved in two weeks? Not all documents need to go through all the stages of document creation and approval. However, depending on the document, one or more of the steps will be required.

Some of the review steps defined here would also be considered part of a quality control process for the documents.




Role


The Document Life Cycle


Plan the document

Sometimes you can sit down and just start writing your document. Other times you need to prepare and plan. This is especially true as your document gets larger and more complex. In many cases you are not able to start writing because you do not have your thoughts structured. Preparation and planning, which includes outlining the content and structuring the sections, will help you get started.


Create the initial document draft

In this step, the document draft is created. If there are no subsequent reviews and approvals, this step results in the creation of the final deliverable. Most of the effort associated with the document is used in this step. Subsequent steps may take a long duration, but they do not take nearly as much effort.


Circulate document for feedback and modify as appropriate

These two steps involve circulating the document for initial review and feedback. The document is updated based on the review comments. Depending on the particular document, this may be an iterative step. A document may have an internal review, followed by a stakeholder review, followed by a management review. After each of these reviews, the document is subsequently modified based in the feedback and sent to the next step.



Gain document approval

When the document has been circulated for feedback and subsequently updated, it will be ready for final approval. Some documents should be formally approved in writing. Others are simply considered complete after the final round of feedback is received.

Like all completed (production) deliverables there may be subsequent updates or enhancements that may require their own mini-document life cycle as well.

Transition Documents to the Right Area After the Project

After the project has completed, some of the documents may be archived, while others need to be maintained indefinitely. For instance, project Status Reports can be archived (or purged) when the project has completed, since they are time-sensitive and have limited value after the project is completed. On the other hand, you should save a User’s Manual after the project is completed. These saved documents can continue to be updated in the document repository if the repository is something that is utilized by the entire organization. Otherwise these long-term documents will need to be moved to the document repository used by the support team.

Some companies maintain a central repository of major project deliverables that can be leveraged for reuse. For instance, the Business Requirements document that was created for your project may be able to be leveraged by another project that is looking into a similar business area. The Testing Strategy your project defined may be able to be reused by another project with similar testing needs. After your project has ended, the project manager and librarian should determine the information that can be leveraged on future projects if the organization has a repository where the documents can be saved.

Five Strategies for the Risk Response

Use One of Five Strategies for the Risk Response

Once risks have been identified, there are a number of options that the project manager should consider for responses.

* Leave it. In this approach, the project manager looks at the risk and decides to do nothing. This can happen for a couple reasons.

1. The project manager may feel that the risk should be managed, but that the negative impact of the risk is not worth the cost and effort required to manage the risk. In this case you would rather deal with the costs of the risk occurring that the cost of trying to manage the risk.
2. There may not be any reasonable and practical activities available to manage the risk. This is different from the prior reason where the cost was more than the benefit. In this case, there is no practical way to manage the risk, even if the risk has been identified as high. For instance, it is possible that there is a risk of your sponsor leaving and a new sponsor canceling the project. In fact, you may know that the sponsor is up for a promotion and that this scenario has some possibility of occurring. However, you may not be in a position to do much about it as long as the current sponsor is in place, and you may just need to leave it and see how events play out.

* Monitor the risk. In this case, the project manager does not proactively manage the risk, but monitors it to see whether it is more or less likely to occur as time goes on. If it looks more likely to occur, the team must formulate a different response at a later time. This approach can work for serious risks that are not likely to occur. Rather than put a plan in place immediately, the project manager creates a plan only if it looks likely that the risk will occur. The advantage is that scarce resources are expended only on those risks that are likely to occur. The disadvantage is that the delay in addressing the risk might make it less likely that the risk can be successfully managed in the future.

This is also a good approach if you have identified a risk that should be managed, but the risk event is far off in the future. For instance, if your risk event is nine months in the future, it may not make sense to spend resources to manage the risk at this time. A better approach might be to monitor the risk on a monthly basis. It is possible that over time the risk will go away because of other circumstances. However, if it does not go away, the team will still need to manage the risk in the coming months.

* Avoid the risk. Avoiding the risk means that the condition that is causing the problem is eliminated. One example is that if you find that a part of the project has high risk associated with it, that whole part of the project is eliminated. The risks associated with a particular vendor, for instance, might be avoided if another vendor is used instead. This is a very effective way to eliminate risks but obviously can be used only in certain unique circumstances. In another example, you may have a project risk associated with implementing a solution in multiple locations. Once the risk is identified, the sponsor may change the scope of the project to only implement in one location. In this way, the risk of implementing at multiple locations has been avoided.
* Move the risk. In some instances, the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party. For instance, outsourcing a function to a third party might eliminate that risk for the project team. The third party might have particular expertise that allows them to do the work without the risk. Even if the risk is still present, it now is up to another party to resolve.

Another example of moving the risk is buying insurance. In a simple example, you may have a very fragile and valuable piece of equipment that needs to be shipped to your project team. There is some risk that the material will be damaged. You might move the financial risk by purchasing insurance on the shipment. Of course, if the shipment is damaged, you may still lose time waiting for a replacement part to be shipped. However, you no longer have the financial risk. In exchange for an insurance premium payment, the insurer now has the financial risk.

* Mitigate the risk. In most cases, this is the approach to take. Mitigating the risk means that you put in place a set of proactive steps to ensure that the risk does not occur, or that the impact of the risk event in minimized. Both are valid mitigation strategies. (For the purposes of the TenStep Project Management Process, it is generally assumed that Risk Management Plans are put in place to mitigate the risk.)