The project approach is a section in the Project Charter that describes in words the thinking that goes into the creation of the project schedule. There are two benefits to creating an approach section. First, this information will help the client and stakeholders understand how the project will progress without having to interpret the actual schedule.
The other benefit of the project approach is that it allows the project manager and project team to lay out a high-level vision for project execution and use this vision to help create the lower-level schedule. Sometimes the project team finds it hard to build a schedule to complete the work. Creating a high-level approach first can make it easier to create the lower-level schedule second.
There are a number of ways the section can be prepared. Usually, you start off with general content about how the organization and environment will impact the project. Then you walk chronologically through the project, starting at the beginning and going to the end. Of course, you don't describe the detail at an activity level. You want to stay at the milestone, stage or phase level.
Sometimes it is difficult to get started with this section. The following information gives you more detail and examples of the areas that can be described. You will notice that much of this information may be available elsewhere, but it is in the approach section that you tie everything together in context for the benefit of the reader.
*Discuss whether any broader company initiatives or strategies impact the structure of this project.
*Identify any constraints or time-boxes in terms of budget, effort, time or quality, and the impact to the project.
*Describe any company standards that will impact how the project is executed.
*Note any company or industry best practices that will have an effect on the project.
*Describe other options for the overall approach and why you chose the options you did over the others. Note why you think this approach has the best chance of success over the others.
*Talk about how the deliverables will be supported and maintained after the project ends. Also indicate whether the approach was influenced by support and maintenance implications.
*Discuss any other related projects that are completed, in progress or pending that influenced the approach for this project and why.
*Discuss, at a high level, how the project will progress from start to end and the interdependencies between the high-level phases and stages.
*Discuss any techniques that might be of interest to the reader. For instance, if the requirements will be gathered in a three-day Joint Application Design (JAD) session, you can note this in the approach.
*Note whether new technology or new processes are being utilized and why.
*Identify any unusual staffing requirements, such as consultants or outside specialists, and explain why you need them.
*Describe the use of outsourcers, contractors or vendors, especially if they are doing significant work.
*Of course, these are ideas for the approach section. You do not need to comment on all of them and many may not be applicable to your project. The purpose of the approach is to describe these factors and the impact they have on the project schedule. This section generally is for the benefit of the reader - the writer already knows the information. There is a tendency to write this section briefly and quickly, therefore providing little value to the reader. If the writer is diligent and provides good context, this section can instead prove to be very valuable for the reader.
Wednesday, May 20, 2009
Wednesday, July 2, 2008
Deliver More than the Client Requested
Don't 'Goldplate' (Deliver More than the Client Requested)
The term goldplating refers to delivering more than what the client requested. Even though it might seem that this is a good thing, it is wrong for two reasons. First, the primary focus of the project should be to make sure that you deliver what the client wants - on time and within budget. By adding in additional work, you increase the risk that the project will not meet its deadline or budget. If you end up missing your deadline date, you will not find sympathy if you explain that the date was missed because of adding more work than the client agreed to.
Second, if you deliver more than the client expected, there is always the implication that you could have delivered what they wanted for less time and duration. if you goldplate, you are taking it upon yourself to make a business decision on what is of most value to the client. There may be some good reasons why the additional features were not included in the initial project scope. They may, in fact, be of marginal value to the client. There may be more value in having the solution completed early and for less cost. The point is that this is a client decision and not one that the project manager should make.
Under-promising and over-delivering should only apply to delivering earlier or for less money than was anticipated. It should not include delivering more requirements than were asked for. The client may, in fact, ask you to include more requirements in the solution. If they do, the new requirements should be processed through scope change management. However, the client may have other uses for the savings that are more important to them. If you can complete the project earlier or for less money than was budgeted, let the client make the decision on what to do with the good fortune.
Make Sure Quality Management Focuses on Processes, Not People
The focus of quality management is to build the right processes so that the entire team can produce the deliverables that meet the client's expectations. Therefore, if a particular deliverable has a quality problem, the project manager and project team should focus on how the project work processes can be improved - not on trying to determine who is to blame.
Most problems with quality are the result of poor or inadequate work processes, not because of the malicious act of a particular person. In fact, it is thought that at least 80% of quality problems can be resolved by changing and strengthening business processes. Less than 20% of problems are under a team member's control. Furthermore, the processes that your organization utilizes are largely determined by management. So, when workers or team members have quality problems, it is important for managers to identify the weak or broken processes involved and fix them. This is a management responsibility ' not the responsibility of the staff. This does not mean that everyone cannot be involved. However, the setting up and enforcement of business processes is primarily a management responsibility.
The term goldplating refers to delivering more than what the client requested. Even though it might seem that this is a good thing, it is wrong for two reasons. First, the primary focus of the project should be to make sure that you deliver what the client wants - on time and within budget. By adding in additional work, you increase the risk that the project will not meet its deadline or budget. If you end up missing your deadline date, you will not find sympathy if you explain that the date was missed because of adding more work than the client agreed to.
Second, if you deliver more than the client expected, there is always the implication that you could have delivered what they wanted for less time and duration. if you goldplate, you are taking it upon yourself to make a business decision on what is of most value to the client. There may be some good reasons why the additional features were not included in the initial project scope. They may, in fact, be of marginal value to the client. There may be more value in having the solution completed early and for less cost. The point is that this is a client decision and not one that the project manager should make.
Under-promising and over-delivering should only apply to delivering earlier or for less money than was anticipated. It should not include delivering more requirements than were asked for. The client may, in fact, ask you to include more requirements in the solution. If they do, the new requirements should be processed through scope change management. However, the client may have other uses for the savings that are more important to them. If you can complete the project earlier or for less money than was budgeted, let the client make the decision on what to do with the good fortune.
Make Sure Quality Management Focuses on Processes, Not People
The focus of quality management is to build the right processes so that the entire team can produce the deliverables that meet the client's expectations. Therefore, if a particular deliverable has a quality problem, the project manager and project team should focus on how the project work processes can be improved - not on trying to determine who is to blame.
Most problems with quality are the result of poor or inadequate work processes, not because of the malicious act of a particular person. In fact, it is thought that at least 80% of quality problems can be resolved by changing and strengthening business processes. Less than 20% of problems are under a team member's control. Furthermore, the processes that your organization utilizes are largely determined by management. So, when workers or team members have quality problems, it is important for managers to identify the weak or broken processes involved and fix them. This is a management responsibility ' not the responsibility of the staff. This does not mean that everyone cannot be involved. However, the setting up and enforcement of business processes is primarily a management responsibility.
Thursday, June 26, 2008
Consider Green Project Management Concepts
The world is going green and it appears that the United States is starting to get the message as well. We are collectively realizing that we do not have an unlimited amount of air or water or space to continue to utilize resources as we have done in the past. The pending crises of global warming merely serves as the central rallying point for an environmentally friendly movement that has been underway since at least the 1970s.
How can we apply these “green” concepts to our project management discipline? One obvious way is that we can manage green projects more efficiently. For example, if you are the project manager on a project that will result in a using less packaging in your products, it would be good if your project completed on time. The sooner that project ends, the sooner the green benefits will be achieved.
On the other hand, most project managers do not run these kinds of projects. Most of us deal with projects such as installing a new software package or upgrading network infrastructure. How can these projects become more environmentally friendly?
The answer is green project management.
Green project management is a model where we think green throughout our project and make whatever decisions make sense in a way that is friendlier to the environment. It is a way to ingrain “greenthink” into every project management process. Here are some examples:
Project Charter
I have seen many Project Charters in many templates. However, I have never seen a charter with a section on environmental concerns. Therefore, I am sure that most project managers never give it a thought as they are defining the project. I am also sure that few project sponsors give it a thought either.
But are there ways that your project can be greener is you would only think about it. For instance, if you are upgrading your network infrastructure, it is likely that some of your equipment will be obsolete. If you do what I did 20 years ago, you might take the old equipment and bury it in the middle of a big dumpster. However, maybe the better choice is to seek out a recycling company. You know what – it might even cost you a few bucks. However, if you identify it up front you can build the cost into your estimate.
Managing Issues
You know the process - identify an issue, determine the cause, estimate the impact to your project, look for alternatives, make recommendations, etc. Mow let me add a section to your Issues Resolution template to identify environmental impacts. I am not saying that every alternative will have any impact one way or the other. I am just saying to apply “greenthink” to the process.
For example, let’s say that you have an issue that will require an additional six hours of user testing to resolve. One option would be for the testers to work in the evening to complete the work with the least disruption to the schedule. Of course, you want to understand the impact of this evening testing such as poor morale and overtime pay.
If you had a section on your form for the environmental impact, you might also include the energy required to run air conditioning (or heat), lighting, water, etc. I know many of you are saying this is crazy because the costs are so low. However, it is not the costs we are worried about. It is the impact on the environment of using the extra electrical, natural gas, water, etc. I also know the impact is small, but consider that you are making these decisions along with millions of other people also making similar decisions. It could all add up. In fact, I taught a class at an Eastern European country last year where they might choose to delay the project for a day rather than use these additional natural resources.
The Point ...
The point about green project management is not that we make every decision in favor of the one that is most environmentally friendly. The point is that we start to take the environment into account instead of ignoring it. You might make most decisions the same as you do today. But there might be some decisions you would make differently. These different decisions, multiplied by tens of thousands each day across the world, can make a difference.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
How can we apply these “green” concepts to our project management discipline? One obvious way is that we can manage green projects more efficiently. For example, if you are the project manager on a project that will result in a using less packaging in your products, it would be good if your project completed on time. The sooner that project ends, the sooner the green benefits will be achieved.
On the other hand, most project managers do not run these kinds of projects. Most of us deal with projects such as installing a new software package or upgrading network infrastructure. How can these projects become more environmentally friendly?
The answer is green project management.
Green project management is a model where we think green throughout our project and make whatever decisions make sense in a way that is friendlier to the environment. It is a way to ingrain “greenthink” into every project management process. Here are some examples:
Project Charter
I have seen many Project Charters in many templates. However, I have never seen a charter with a section on environmental concerns. Therefore, I am sure that most project managers never give it a thought as they are defining the project. I am also sure that few project sponsors give it a thought either.
But are there ways that your project can be greener is you would only think about it. For instance, if you are upgrading your network infrastructure, it is likely that some of your equipment will be obsolete. If you do what I did 20 years ago, you might take the old equipment and bury it in the middle of a big dumpster. However, maybe the better choice is to seek out a recycling company. You know what – it might even cost you a few bucks. However, if you identify it up front you can build the cost into your estimate.
Managing Issues
You know the process - identify an issue, determine the cause, estimate the impact to your project, look for alternatives, make recommendations, etc. Mow let me add a section to your Issues Resolution template to identify environmental impacts. I am not saying that every alternative will have any impact one way or the other. I am just saying to apply “greenthink” to the process.
For example, let’s say that you have an issue that will require an additional six hours of user testing to resolve. One option would be for the testers to work in the evening to complete the work with the least disruption to the schedule. Of course, you want to understand the impact of this evening testing such as poor morale and overtime pay.
If you had a section on your form for the environmental impact, you might also include the energy required to run air conditioning (or heat), lighting, water, etc. I know many of you are saying this is crazy because the costs are so low. However, it is not the costs we are worried about. It is the impact on the environment of using the extra electrical, natural gas, water, etc. I also know the impact is small, but consider that you are making these decisions along with millions of other people also making similar decisions. It could all add up. In fact, I taught a class at an Eastern European country last year where they might choose to delay the project for a day rather than use these additional natural resources.
The Point ...
The point about green project management is not that we make every decision in favor of the one that is most environmentally friendly. The point is that we start to take the environment into account instead of ignoring it. You might make most decisions the same as you do today. But there might be some decisions you would make differently. These different decisions, multiplied by tens of thousands each day across the world, can make a difference.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Wednesday, May 14, 2008
Make Sure Your Measures Add Value
Identifying, gathering and leveraging the right mix of metrics are ways to add value to a project. The value can be quantified in a number of areas including:
* Improved performance of the overall project fulfillment and delivery process
* Improved estimating for future projects
* Validation of duration, cost, effort and quality objectives for the project
* Identification and communication of best practices
* Improved client satisfaction
In general, metrics provide a more factual and quantitative basis for understanding how you are doing and the things that can be done better. Without at least some basic metric information, all discussions on performance and improvement are based on anecdotal evidence, perceptions and guesses. If you want your project's success or failure to be based on factual information, you need to determine the success criteria ahead of time and how to measure these criteria. Then collect the metrics, even if they are imperfect and imprecise. They still provide a better foundation than nothing at all.
Use the Metrics that You Collect
You don't want to collect metrics just for the sake of collecting them. That doesn’t make sense from a project management perspective and it just ends up being a waste of time. If certain metrics are required by your organization, collect them. In addition, you should collect any other metrics that are needed by your particular project. However, if you don't have a purpose for the metrics, or if your project is not long enough that you can really leverage the information, these customized project-specific metrics are not worth collecting for your project.
Compare the Cost of Collecting a Metric vs. the Benefit
Just as there is some cost associated with most project management activities, there is a cost to collecting and managing a metrics process. In the case of scope management or issues management, this is a cost the project manager needs to invest in to be successful, since they are core project management processes. The effort associated with managing metrics, however, is more under the discretion of the project manager and is dependent on the overall organizational culture. In many cases, the cost to collect and leverage a certain type of metric is prohibitive. These metrics should not be pursued. Other metrics are interesting, but do not provide the type of information that can be leveraged for improvement. The bottom line is that the cost to gather each metric must be balanced against the potential benefit that will be gained. Start by gathering metrics that are required by the organization. Then add metrics that have the lowest cost and effort to collect and can provide the highest potential benefit.
Link Team Performance with Individual Performance
This old adage about “what gets measured gets done” is true on projects. If communication is important on your project, build some metrics around communication. For instance, you can survey the clients and stakeholders on a quarterly basis to see how effective they think your communication is. If you are encouraging your team to reuse existing components, track the instances of reuse and the hour and cost savings.
However, you still may not drive the behaviors you need if the results of the metrics do not have a corresponding personal impact on the team members. The key is to collect metrics that give a quantifiable indication of overall team performance and make sure there is a connection between team performance and individual performance.
An example of where these are not linked is the classic case of the project that is seen as a failure, yet all the team members are evaluated highly on their performance reviews. Make sure that project team success is reflected appropriately in the individual performance reviews. If the team was successful, team members should be rewarded. If the team was not successful, team member reviews should be impacted accordingly.
* Improved performance of the overall project fulfillment and delivery process
* Improved estimating for future projects
* Validation of duration, cost, effort and quality objectives for the project
* Identification and communication of best practices
* Improved client satisfaction
In general, metrics provide a more factual and quantitative basis for understanding how you are doing and the things that can be done better. Without at least some basic metric information, all discussions on performance and improvement are based on anecdotal evidence, perceptions and guesses. If you want your project's success or failure to be based on factual information, you need to determine the success criteria ahead of time and how to measure these criteria. Then collect the metrics, even if they are imperfect and imprecise. They still provide a better foundation than nothing at all.
Use the Metrics that You Collect
You don't want to collect metrics just for the sake of collecting them. That doesn’t make sense from a project management perspective and it just ends up being a waste of time. If certain metrics are required by your organization, collect them. In addition, you should collect any other metrics that are needed by your particular project. However, if you don't have a purpose for the metrics, or if your project is not long enough that you can really leverage the information, these customized project-specific metrics are not worth collecting for your project.
Compare the Cost of Collecting a Metric vs. the Benefit
Just as there is some cost associated with most project management activities, there is a cost to collecting and managing a metrics process. In the case of scope management or issues management, this is a cost the project manager needs to invest in to be successful, since they are core project management processes. The effort associated with managing metrics, however, is more under the discretion of the project manager and is dependent on the overall organizational culture. In many cases, the cost to collect and leverage a certain type of metric is prohibitive. These metrics should not be pursued. Other metrics are interesting, but do not provide the type of information that can be leveraged for improvement. The bottom line is that the cost to gather each metric must be balanced against the potential benefit that will be gained. Start by gathering metrics that are required by the organization. Then add metrics that have the lowest cost and effort to collect and can provide the highest potential benefit.
Link Team Performance with Individual Performance
This old adage about “what gets measured gets done” is true on projects. If communication is important on your project, build some metrics around communication. For instance, you can survey the clients and stakeholders on a quarterly basis to see how effective they think your communication is. If you are encouraging your team to reuse existing components, track the instances of reuse and the hour and cost savings.
However, you still may not drive the behaviors you need if the results of the metrics do not have a corresponding personal impact on the team members. The key is to collect metrics that give a quantifiable indication of overall team performance and make sure there is a connection between team performance and individual performance.
An example of where these are not linked is the classic case of the project that is seen as a failure, yet all the team members are evaluated highly on their performance reviews. Make sure that project team success is reflected appropriately in the individual performance reviews. If the team was successful, team members should be rewarded. If the team was not successful, team member reviews should be impacted accordingly.
Wednesday, May 7, 2008
Manage Issues - Large Projects
Use the following process to manage issues on large projects.
1. Identify the problem and document on the Issues Form
Solicit potential issues from any project stakeholders, including the project team, clients, sponsors, etc. The issue can be surfaced through verbal or written means, but it must be formally documented using an Issues Form.
2. Determine if the problem is really an issue
The project manager determines whether the problem can be resolved or whether it should be classified as an issue.
3. Enter the issue into the Issues Log
If it is an issue, the project manager enters the issue into the Issues Log.
4. Determine who needs to be involved in resolving the issue
The project manager determines who needs to be involved in resolving the issue. The sponsor may be involved, or the sponsor may not have the expertise to assist in the resolution process. For instance, the resolution may require technical or legal staff. The problem may be contractual and require resolution from the Purchasing Department. However, at some point the alternatives will be discussed and a resolution will be made. It is important to understand up-front who needs to be involved in making this final issue resolution.
5. Assign to team member for analysis and alternatives
The project manager assigns the issue to a project team member for investigation (the project manager could assign it to himself or herself). The team member will investigate options that are available to resolve the issue. For each option, the team member should also estimate the impact to the project in terms of budget, schedule and scope.
6. Gain agreement on resolution
The various alternatives and impact on schedule and budget are documented on the Issues Form. The project manager should take the issue, alternatives and project impact to the project sponsor and other appropriate stakeholders for discussion and resolution. The project manager may want to make a recommendation from among the alternatives as well.
7. Close the Issues Log
The project manager documents the resolution or course of action on the Issues Log.
8. Close the Issues Form
The project manager documents the issue resolution on the Issues Form and then closes and files this document.
9. Add action plan to the schedule
Once a resolution is agreed upon, the appropriate corrective activities are added to the schedule to ensure the issue is resolved.
10. Update Charter, if necessary
If the resolution of an issue causes the budget, effort or duration of the project to change, the current Project Charter should be updated.
11. Communicate through the Status Report
The project manager communicates issue status and resolutions to project team members and other appropriate stakeholders through the methods established in the Communication Management Plan, including the project Status Report.
1. Identify the problem and document on the Issues Form
Solicit potential issues from any project stakeholders, including the project team, clients, sponsors, etc. The issue can be surfaced through verbal or written means, but it must be formally documented using an Issues Form.
2. Determine if the problem is really an issue
The project manager determines whether the problem can be resolved or whether it should be classified as an issue.
3. Enter the issue into the Issues Log
If it is an issue, the project manager enters the issue into the Issues Log.
4. Determine who needs to be involved in resolving the issue
The project manager determines who needs to be involved in resolving the issue. The sponsor may be involved, or the sponsor may not have the expertise to assist in the resolution process. For instance, the resolution may require technical or legal staff. The problem may be contractual and require resolution from the Purchasing Department. However, at some point the alternatives will be discussed and a resolution will be made. It is important to understand up-front who needs to be involved in making this final issue resolution.
5. Assign to team member for analysis and alternatives
The project manager assigns the issue to a project team member for investigation (the project manager could assign it to himself or herself). The team member will investigate options that are available to resolve the issue. For each option, the team member should also estimate the impact to the project in terms of budget, schedule and scope.
6. Gain agreement on resolution
The various alternatives and impact on schedule and budget are documented on the Issues Form. The project manager should take the issue, alternatives and project impact to the project sponsor and other appropriate stakeholders for discussion and resolution. The project manager may want to make a recommendation from among the alternatives as well.
7. Close the Issues Log
The project manager documents the resolution or course of action on the Issues Log.
8. Close the Issues Form
The project manager documents the issue resolution on the Issues Form and then closes and files this document.
9. Add action plan to the schedule
Once a resolution is agreed upon, the appropriate corrective activities are added to the schedule to ensure the issue is resolved.
10. Update Charter, if necessary
If the resolution of an issue causes the budget, effort or duration of the project to change, the current Project Charter should be updated.
11. Communicate through the Status Report
The project manager communicates issue status and resolutions to project team members and other appropriate stakeholders through the methods established in the Communication Management Plan, including the project Status Report.
Wednesday, April 30, 2008
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.
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.
Monday, April 28, 2008
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.
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.
Subscribe to:
Posts (Atom)