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.

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.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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.

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.

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.)

Managing Outsourced Projects

Outsourcing of project work is more common today than ever. However, even though you outsource the work, you cannot completely outsource your obligation to make sure the project is progressing smoothly. If all goes well with the outsourcer, you do not have much work to do. Unfortunately, in many instances, the outsourcing vendor does not perform against expectations. If that happens, you want to know about it as soon as possible. For the purposes of this discussion, let us assume that your company has outsourced a project, or a portion of a project. Your company has also asked you to manage the relationship to ensure the vendor performs as expected.

Many people are not sure what they should be doing when they are asked to manage an outsourcing relationship. Part of the uncertainty is because some of the project roles are reversed when you outsource work to a third-party. On a normal internal project, the project manager assigns the work and manages issues, scope, risk, quality, etc. The project manager makes sure work is done on time and the project is progressing as it should. He is held accountable for the success of the project. Other people perform a quality assurance role to make sure things are progressing as they should.

With an outsourced project, the vendor takes on the direct management of the outsourced work. The client project manager is now the one that has to ask the quality assurance questions to make sure the vendor project is progressing as it should. Some of the up-front questions to ask include:

*

Is there a contractual agreement that spells out the expectations of both parties in terms of deliverables to be produced, deadlines, payment schedule, completeness and correctness criteria, etc?
*

Has a comprehensive project schedule been created?
*

What is the Project Management Plan the vendor will use to control the project?
*

Has the vendor been clear on what resources will be needed from your company and when they will be needed?
*

Have a number of agreed-upon milestones been established to review progress so far and validate that the project is on-track for completion?

Ongoing Questions

As the project is progressing, you must continue to ask questions to determine the current state of the work. You may have status meetings weekly, but there should be a formal quality assurance check at the end of every agreed-upon milestone. The types of questions you would ask at every milestone include:

*

Have the deliverables specified in the Project Charter been completed up to this point?
*

Have the appropriate deliverables been agreed to and approved by the company?
*

If the vendor has met expectations up to this point, have any interim payments been released?
*

Can the vendor clearly explain where the project is vs. where it should be at this time?
*

Will all the future deliverables specified in the Project Charter be completed?
*

Are issues, scope, and risks being managed as stated in the Project Management Plan?
*

Should the contract or Project Charter be updated to reflect any major changes to the project?

Once you understand your role on the project, it is easier to ask the right questions to make sure that everything is progressing as it should.

The Discovery Project

For large projects, there is a tendency for the project definition process to become very lengthy and unfocused. Defining the work for very large projects takes enough time that it should be structured as a project itself. This is the purpose of defining a separate Discovery Project.

This should make sense. If the project is ultimately going to take 50,000 effort hours, it may take a number of months to get the project defined and approved. In these cases, a distinct first project is established to define the second larger project itself. The final deliverable for a Discovery Project is a completed Project Charter, Project Management Plan and project schedule for the subsequent large project. For the most part, all the other deliverables will be produced as a part of the next follow-up project.

The Discovery Project should be planned and managed as a project. This includes defining the work, building a schedule and budget and subsequently managing the Discovery Project. You want to make sure you are clear on what is expected at the conclusion of a Discovery Project.

Discovery Projects, like all projects, come in all sizes. You should estimate the effort and duration required for the Discovery Project. Based on the effort required for the Discovery Project, you can categorize the Discovery Project itself as small / medium / large. Remember that this is the relative size of the Discovery Project, not the final project. Depending on the size of the Discovery Project, you again have three options on how to define the work.

For a small Discovery Project, a service request can be created to define the work. Even thought he Discovery Project is small, you can assume that the final project deliverable will be a full Project Charter and a project schedule for the subsequent project.

For a medium-sized Discovery Project, you should follow the TenStep Project Management Processes for defining and managing a medium project. The Discovery Project should have an Abbreviated Project Charter and project schedule, and be managed just like any other medium-size project, including managing issues, scope, risk, etc. When the Discovery Project is complete, the Project Charter, Project Management Plan and project schedule for the subsequent project should be created. The approval process for these documents should be a part of the Discovery Project. Assuming that the Project Charter is approved, the subsequent larger project can start at any time. However, the TenStep steps 1.0 Define the Work and 2.0 Build the Schedule and Budget will already be completed. (These planning processes were the purpose of the Discovery Project). The project management process for this subsequent project can begin in Step 3.0 Manage the Schedule and Budget.

If the size of your Discovery Project is, in fact, a large project itself, you should follow the steps required for defining large projects. You would want a full Project Charter to define the Discovery Project, and you would want a full project schedule, budget and Project Management Plan. If the Discovery Project is a large project, the subsequent project will generally be huge - perhaps a program of related projects. Similar to a medium project, the Discovery Project would create the Project Charter, schedule, budget and Project Management Plan for the subsequent larger project (or program). Assuming that the Project Charter is approved, the subsequent larger project can start after the Discovery Project is completed.

Manage Documents on Projects

Project and Project Management Documents

The document repository holds all the project deliverables - both project-related and project management-related. For instance, the repository will hold the Project Charter and project schedule (project management deliverables), as well as the Technical Design and Testing Plan (project deliverables). When you start to consider your document management process, all of the documents your project produces must be taken into account.

Document Workareas

Usually the document repository does not hold documents that are currently being worked on (this may also depend on any document management software being used). Each team member should have a workarea where he or she can store versions of documents that are currently in-progress but not yet in circulation. This can be a directory structure or a folder that each team member has full access to. Team members can structure their work area in whatever way makes sense to them.

Draft Copies

Draft copies are documents that have been initially completed by the author, but are not yet ready to be considered entirely complete from a project perspective. In most cases, this is because the document is in some kind of review process. Draft copies of documents could be stored in the author's workarea. However, for large projects, or ones where more rigor in document management is needed, it will make sense to maintain a library or folder for draft copies. In this case, the update process would look as follows:

1.

A document is created and edited in the author's workarea.
2.

After the initial draft is completed, the document is moved from the workarea to the draft library. The document stays there until the author needs to update it or it is ready to be moved to the repository as an approved document.
3.

When the document is in the draft library, it can be circulated for review and input.
4.

If the draft copy needs to be updated again, the document is copied back to the workarea for updating, leaving a copy in the draft library.
5.

This process is repeated until the document is totally complete. Then the document can be moved from the draft library to its final location in the document repository.

The value in this approach is that the project team always has one official draft of each document and only one live, approved version as well.

Garbage in – Garbage Out

This classic problem still exists in document management no matter how sophisticated your processes become. Document management helps you store and retrieve information that already exists in the project. However, even if you find the document, the content may or may not be helpful. Team members need to understand that their documents must be well-written so that others can read them and understand the content. On some projects, team members search for documents, find them, but then discover that the content in them is unusable. Your document management processes may help in these situations by getting others, including the librarian, involved in reviewing documents before they are added to the repository. However if you allow poorly-written documents to be added to the repository, you may find that people are not going to utilize the repository as often since they will not perceive value in the documents that the repository contains.

Document Management Technology Will Influence Your Process

Much of the process for managing documents is influenced by any document management technology used on the project. For instance, document management software will usually come with a standard logical structure. You just plug in your specific names to make it real. Software may also enforce versioning and have features for controlling update authority. The tool may also describe the metadata needed for keywords and indexing.

Calculating the Critical Path

ES – Early Start

EF – Early Finish


LS – Late Start

LF - Late Finish

There is a manual method for calculating the critical path. This involves looking at the earliest start date (ES) and earliest finish dates (EF) for every activity starting at the beginning of a project and moving to the end of the project. You then start at the end of the project and go backward, looking at the latest possible start dates (LS) and latest finish dates (LF) for every activity. The difference between the latest start day and the earliest start day for each activity is the activity float (this will end up being the same as the difference between the latest end day and the earliest end day). You then look for the sequence of activities from start to end that have zero float. This is the critical path.

1.The forward pass involves starting at the first activity in the network diagram and calculating the earliest that every activity can start (ES) and the earliest every activity can finish (EF).

2. Once the final activity is scheduled using the forward pass, you start at the end and work backward. The backward pass involves calculating the latest that every activity can finish (LF) and the latest every activity can start (ES), while still completing the project on time.

3.The critical path contains activities that all have zero slack.

The Critical Path May Change

There are many sequences of activities on a project to get from the beginning to the end. There may, in fact, be multiple critical paths, if they all have no float and all lead to the same end-date. Usually if there are multiple critical paths, they overlap for many of their activities

Given that there are many, many paths through the workplan, it's possible for the critical path to change. For instance, say you have the same example as above, with 22 activities over nine months. Let's assume that there is another path of work that includes 19 activities and takes 8 1/2 months. If you tried to accelerate the schedule to complete the project in eight months, it gets a little complicated. First you would want to focus on accelerating the activities in the nine month critical path. However, once the critical path is reduced to 8 1/2 months, this second critical path emerges that has the same overall timeline. Compressing the original critical path further will not make the project end earlier, because this second path is still going to take 8 1/2 months to complete. In this case, both paths must be accelerated (or perhaps some activities that are common to both can be accelerated).

The other way the path may change is if activities off the critical path get delayed. In the example above, let's say that one of the activities on the 8 1/2 month path ends up taking an extra three weeks. Because there was only two weeks of float in the path, it will now become the critical path and force the entire project to complete one week late.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Defining Scope

Defining Scope

Defining scope is perhaps the most important part of the upfront definition and planning process. If you don't know for sure what you are delivering and what the boundaries of the project are, you have no chance for success. If you have not done a good job of defining scope, managing scope will be almost impossible.

The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more aspects of scope you can identify, the better off your project will be. The following types of information can be helpful in defining scope.

*

The deliverables that are in scope and out of scope. You should definitely include deliverables in your scope statements. However, only describe your final deliverables and the project deliverable that are client-focused. For instance, the Business Requirements Report and Current State Assessment could be listed as project deliverables since they are both client-approved deliverables. You would not need to mention internal project documents such as the project workplan, Technical Design or Test Cases.
*

The major lifecycle processes that are in scope and out of scope. For instance, your project may include the Analysis Phase only and not the Design, Construct or Test Phases.
*

The types of data that are in scope and out of scope. Data types refer to financial data, sales data, employee data, etc. It is possible that your project works with some types of data and does not work with others.
*

The data sources (or databases) that are in scope and out of scope. This is similar to the data types, except now you are referring to aggregated data, such as Customer Database, General Ledger, Billing / Invoicing System, etc. (These data sources may have more than one data type.)
*

The organizations that are in scope and out of scope. In some cases, the organizations involved in the project help to define the boundaries. For instance, your project may focus on Human Resources and Accounting, but the Manufacturing Division might be out of scope.
*

The major functionality that is in scope and out of scope. For instance, decision support and management reporting might be in scope, while overnight batch processing might be out of scope.

Use High-Level Objectives as Your Starting Point

When the project was proposed for funding, there should have been an initial set of high-level objectives and deliverables defined. Any information that was created earlier should be used as the starting point for defining the more detailed scope statements for the Project Charter. If you find that you do not have enough information to create a clear and comprehensive scope statement, you must work with the sponsor to gather additional information. That is one of the main purposes of the definition and planning process.

If you have project objectives, look at them to help shape the scope statements. By definition, there needs to be one or more deliverables created to fulfill each objective, and defining the project deliverables is one of the primary aspects of project scope. After you determine the major deliverables the project will produce, start asking other questions to determine other aspects of scope. The deliverables describe 'what' the project will deliver. You can also identify 'what' organizations are impacted, 'what' types of data are needed, 'what' major features and functions are needed, etc.

As a point of clarity and contrast, you can also identify out-of-scope conditions by describing what deliverables will not be created, what organizations will not be impacted, what features and functions are not included, etc. Of course, there are an infinite number of out-of-scope statements. For the purposes of scope definition, you want to include only those statements that help define the project boundary and touch upon related areas that the reader may have questions about. For instance, if you were installing financial software, you might state that a new Accounts Payable package is in scope, but the related Purchasing System is out of scope. This would make sense because the Purchasing and Accounts Payable processes are related and there may be questions as to whether the Purchasing System was in scope. However, you would not have to list every other system as out of scope � just the ones that the reader might have questions about.

It is a good practice to document those organizations that are in scope and those related organizations that are out of scope. The readers can then determine more easily if they are impacted or expected to assist in the project. Also, it may make sense to identify the organizations that are in scope so that you can have people from those organizations represented on the project team - perhaps on a steering committee.

Aligning Objectives and Scope

When you have completed creating your objectives and scope statements, go back and make sure that they are all in alignment. You should not have any objectives that make references to deliverables that are not defined in your scope statements. Likewise, you don't want to include deliverables in your project scope that do not help to achieve the project objectives. If the two areas are not in full agreement, either the scope or the objectives (or both) must be modified to bring everything into alignment.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Goals and Objectives

Goals are high-level statements that provide overall context for what your organization is trying to achieve in the next three years. Objectives are lower level statements that describe the specific, tangible products and deliverables that the project will deliver. The definition of goals and objectives is more of an art than a science and it can be difficult to define them and align them correctly. However, through practice and the use of some common definitions, you can start to identify and tell the difference between goals and objectives.

Business Goals

Goals are high-level statements that describe what your organization is trying to achieve over a one to three year horizon. For example one of the goals of the IT Support group might be to "increase the overall satisfaction levels for clients calling to the company helpdesk".

Because the goal is at a high-level, it may take more than one project to achieve. In the above example, for instance, there may be a technology component to increasing client satisfaction. There may also be new procedures, new training classes, reorganization of the helpdesk department and modification of the company rewards system. It may take many projects over a long period of time to achieve the goal.

The goal should reference the business benefit in terms of cost, speed and / or quality. In this example, the focus is on quality of service. Even if the project is not directly in support of the business, there should be an indirect tie. For instance, an IT infrastructure project to install new web servers may ultimately allow faster client response, better performance or some other business benefit. If there is no business value to the project, the project should not be started.

If you can measure the achievement of your goal, it is probably written at too low a level and is more of an objective.

If your goal is not achievable through any combination of projects, it is probably written at too high a level. In the above example, you could envision one or more projects that could end up achieving a higher level of client satisfaction. A goal statement that says you are trying to achieve a perfect client experience is not possible with any combination of projects. It may instead be a vision statement, which is a higher level statement showing direction and aspiration, but which may never actually be achieved.

Project Objectives

Objectives are concrete statements that describe the things the project is trying to achieve. An objective should be written at a lower level, so that it can be evaluated at the conclusion of a project to see whether it was achieved. Goal statements are designed to be vague. A well-worded objective will be Specific, Measurable, Attainable/Achievable, Realistic and Time-bound (SMART). (However, SMART is a technique for wording the objective. An objective does not absolutely have to be SMART to be valid.)

An example of an objective statement might be to "upgrade the helpdesk telephone system by December 31 to achieve average client wait times of no more than two minutes".

*

Note that the objective is much more concrete and specific than the goal statement.
*

The objective is measurable in terms of the average client wait times the new phone system is trying to achieve.
*

You can assume that the objective is achievable and realistic.
*

The objective is time-bound, and should be completed by December 31.

Objectives should refer to the deliverables of the project. In this case, the objective refers to the upgrade of the telephone system. If you cannot determine the deliverables that are created to achieve the objective, the objective may be written at too high a level. On the other hand, if an objective describes the characteristics of the deliverables, it is written at too low a level. If the statements describe the features and functions, they are requirements, not objectives.

Importance of Objectives

Objectives are important because they show a consensus of agreement between the project manager and the project sponsor on the main purpose of the project. The specific deliverables of an IT project, for instance, may or may not make sense to the project sponsor. However, the objectives should be written in a way that they are understandable by all of the project stakeholders.

Define Objectives Before the Project Starts

The project objectives and the business goals they support should be defined and agreed upon before the project starts. The deliverables of the project are created based on the objectives - not the other way around. That is, you don't agree on the deliverables first and then establish objectives to match. You must understand the objectives of a project and then determine what deliverables are needed to achieve them.

A facilitated meeting between all major stakeholders is a good way to create the objectives and gain a consensus on them at the same time.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

TenStep Project Management Tip of the Week

Hold Everyone Accountable for Scope Management Process

Many scope management processes work well at the project manager level, but get compromised by team members. If the project manager is diligent in enforcing the scope change rules, the client may try to go directly to team members for changes. For instance, when an agreed-upon report is delivered for review, the client may request a second report to provide more clarity. The team member may agree to the work (showing 'client focus'). The result is that the activity takes too long or resources that could have been applied to other high priority work get absorbed working in an area that is out of scope.

The bottom line is that everyone needs to be held accountable for the scope management process. Team members must understand the process and why it is important. The client must also understand the process and its importance. Don't consider these procedures to be only of interest to the project manager and the sponsor. Make sure the procedures are communicated to the entire team.

When clients request scope changes directly from team members, bring this to the attention of the client manager or the sponsor. When team members make commitments for work that is out of scope, deal with it promptly. The first time it happens it may be considered a training matter. The next time it might be a performance problem.

The Change Control Board

Sometimes on very large projects, the project sponsor does not feel comfortable making the scope change decisions alone. This may especially be the case if the effect of the change will impact other organizations. It may also be the case that multiple organizations are participating in, or contributing to, the project funding, and want to have some say in evaluating scope change requests. For these cases, a group of people might be needed to handle the scope change approval.

A common name for this group is a Change Control Board. If a Board exists, it may be more cumbersome to work through. However, the general scope change management process does not need to change dramatically. For instance, there is still a document for the initial the scope change request. The project team needs to determine the impact and cost to the project. The Board must consider the impact, the value to the project, the timing, etc., and then make a determination as to whether the request is accepted.

The Scope Change Procedures must be somewhat more sophisticated to account for the Board. For instance, you need to clarify who is on the Board, how often they will meet, how they will be notified in emergencies, how they will reach decisions (consensus, majority, unanimous, etc.), how incremental work will be paid for, etc.

Only the Sponsor Can Approve Changes – Not Users and Client Managers

A typical problem on a project is that the team does not understand the roles of the sponsor, client and end users. In general, the project sponsor is the person who is funding the project. If the client were embodied in one person, it would be the project sponsor. The sponsor is usually high up in the organization and not easy to see on a day-to-day basis. In most cases, the sponsor designates someone in his or her organization to make most decisions on a daily basis.

The people that the project team tends to work with most often are end users. End users are the people that use the solution that the project is building. The end users are the ones that will generally make requests for changes to deliverables. It doesn't matter how important a change is to an end user, the end users cannot make scope change decisions and they cannot give your team the approval to make a scope change. In proper scope change management, the sponsor must give the approval. The end users can request scope changes, but they cannot approve them. The end user cannot allocate additional funding to cover the changes and they cannot know if the project impact is acceptable. If the change is important enough to the Sponsor, he or she will approve it, along with the appropriate budget and duration changes. If the change is not important enough, it will not be approved. However, it will be the Sponsor making the decision, not the project manager, client manager, project team or end users.

Five Steps for Updating Your Resume

Five Steps for Updating Your Resume
Caroline Levchuck, Yahoo! HotJobs


It's a new year! And while you may not need an entirely new resume, you should probably freshen up your current credentials.

Updating your resume doesn't have to be too time-consuming or painful, says resume expert Lauren Milligan, founder of ResuMAYDAY, a Chicago-based resume writing and career services firm. She shares five quick tips for breathing new life into your old resume.

1. Start at the End

Don't overwhelm yourself by looking at your entire resume -- yet. "Look at the bottom of your resume and see if there's anything new that you can add. Workshops, professional training, or awards are a quick way to add something current," says Milligan.

2. Where You've Been and Where You're Going

Next, look at the position nearest the bottom of your resume. Milligan advises, "Ask yourself if it's still relevant to your current career goal. If it's not, delete it so you can build on more current accomplishments that will further your career."

If that last position is still somewhat relevant, "Just edit it down. The very first position you held should get the least amount of attention," she reveals.

3. A Year in the Life

Turn your attention toward your current job. Milligan says, "Update any new projects or accomplishments that have occurred over the last year. Even if it's not a promotion, just include anything from 2007 that can be added to it."

4. Update Your Look

Current information deserves a current look. Does your resume look stylish and polished -- or plain, dull, and dated? If so, Milligan believes it may be time to give your resume a face lift. "If you're still using the same resume format you used a few years ago, you should change it to something more suited to the positions you're currently pursuing -- not those you had after graduation."

Also, make your resume available in several formats -- text only, Microsoft Word, and a PDF. "There's a good use for each of these formats. Having a PDF of your resume at the ready implies a little more technical savvy on your part."

5. Proofread. Proofread. Proofread.

Milligan cannot stress enough the importance of proofreading your resume. "Every time you make any changes to your resume, it's possible to introduce another error," says the resume and careers guru. "Proofread it again and again, and ask a few friends to look at it, also. You can never be too careful."

Adds Milligan, "If you have a 'blah' resume, you're leaving yourself open to those jobs that other aren't willing to do. Update it to make it great!"

Projects / Products- TenStep Project Management Tip of the Week

Projects vs. Products

Projects are the way that most new work gets delivered. All projects have certain characteristics in common.

*They all have a beginning and an end.
*All projects are unique. They may be similar to prior projects but they are unique in terms of timeframes, resources, business environment, etc.
*Projects result in the creation of one or more deliverables.
*Projects also have assigned resources - either full-time, part-time or both.

There are other characteristics as well.

Projects can be managed using a common set of project management processes. In fact, a similar set of project management processes can be utilized regardless of the type of project. For instance, all projects should be defined and planned, and all projects should have processes to manage scope, risk, quality, status, etc.

Products on the other hand, are tangible items that are produced by a project, or perhaps purchased from a vendor. (The vendor would have created the initial product through a project.) Project management can be thought of as a process. A product is delivered by a project. �Product management� is an approach for centrally coordinating the activities surrounding the long-term support and enhancement of a product. The person that executes these responsibilities is called a Product Manager.

The product management process can start during the project that created the product. If you purchased the product, the product management process can begin when the product is purchased, or a little earlier in the product evaluation and selection process.

Product Management

The role of a project manager is to plan and manage a project. The role of a product manager is focused on the long-term support of the product within the organization. The product management role includes the following responsibilities.

*Product Planning
o Coordinate product issues and all communication as the primary contact with the product vendor
o Monitor product direction with the vendor and communicate this information to company stakeholders
o Determine which components of the product should be used in the organization
o Identify opportunities for use of the product
* Testing
o Coordinate testing of new products and releases, including coordinating pilots with potential product users
o Determine when a product is �production-ready� based on testing and pilot projects
o Coordinate certification of new products and releases
* Financial Management
o Coordinate negotiation of product contracts, purchase agreements, and maintenance agreements
o Ensure that budget is available for product purchases and maintenance
o Determine when to consider canceling or reducing maintenance payments based on product direction
* Product Implementation and Deployment
o Coordinate development of a product deployment plan
o Manage and monitor the deployment of the product or new releases
o Deploy (distribute) the product
o Track product inventory (where the product has been deployed)
o Receive ongoing requests from the staff for individual product deployment
o Integrate and add new products and releases into the architecture
* Product Release Management
o Decide when to upgrade to a new release
o Plan and manage new release implementation
o Ensure new releases get added into the architecture if required
* Product Retirement
o Determine when product needs to be retired
o Plan and manage product retirement
o Retire (uninstall) the product from the environment
o Ensure product gets removed from the architecture