Managing Client Expectations

Somehow clients always seem to expect more than we are prepared to deliver. This expectation gap is more the result of a failure to communicate than it is of anything else, and this lack of communication starts at the beginning of a project and extends all the way to the end. This definitely does not have to be the case.  It is the project manager’s job to utilize effective and efficient communication to sort out customers needs and to appropriately set customer expectations and team expectations early in the project to ensure the end goals are correct and attainable.  If the end goals are blurry or not specified, then they will never be attainable.

Sorting Wants versus Needs

The root cause of many problems that come up in the course of a project originate in a disconnect between what the client says they want and what they really need. The disconnect may come about because the client is swept up in a euphoria over the technology and is so enamored with what they see for potential technologies and solutions that they have convinced themselves they have to have it without any further thought of exactly what it is they really need.

The disconnect can also come about because the client does not really know what they need. It is the job of the project manager and team to ask the right questions and extract the needs out from behind the wants.  If there is any reason to believe that what the client says they want is different from what they need, the project manager has the responsibility of sifting and sorting this out ASAP. It would be a mistake to proceed without having the assurance that wants and needs are in alignment. You don’t want to start the project not knowing that the solution is in fact what will satisfy the client. The project Statement of Work, or SOW, developed early in the discussion phases of the project will begin to lay this foundation for the project team but may not fully sort out the customer needs from wants.

Problems with listening and communication

If I had to pick one area where most projects run into trouble, I would pick the very beginning. For some reason, people have a difficult time understanding what they are saying to one another. How often do you find yourself thinking about what you are going to say while the other party is talking? If you are going to be a successful project manager, you must stop and listen.  Proactive thinking and planning is great – but not at the expense of hearing what the customer is expressing early in the project planning process.  An essential skill that project managers need to cultivate is good listening skills.

Read more »

The Project Resource Request

Here is yet another template that I am digging out of my archives to provide here.  As you can easily guess, this document is designed for requesting resources at the beginning of your project based on information in your statement of work (SOW) and the estimates of resource requirements that either you or Sales put together in the pre-engagement process.  It is also helpful for requesting additional resources during the project.

How useful this is to anyone depends on the organization they work in.  If you have a mature PMO with processes in place, then I would guess that you already have a standard form or spreadsheet to use to request resource for your project.  However, if you’re one of just a few PMs or personnel acting in a PM role in your organization or you’re in the process of building some PM processes for a newer organization or even setting up a new PMO, then any template may be better than nothing.

As with all of these documents, if you want the original Word doc file, just email me if you think this will be useful or helpful.  And please, provide your own example if you wish.  We’re looking to learn and share information so I’m happy to use and post whatever you would like to provide to the readers of PM Tips.

PROJECT RESOURCE REQUEST

[Save file name as: client name RESOURCE REQUEST yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

WORK DESCRIPTION AND ROLE

Describe the work to be performed on the project by the resource(s) and what role the individual(s) will play on the project team.

DESIRED SKILLS

Describe the technical, business or professional skills needed by the resource(s) to successfully meet the needs of the project.

DELIVERABLES

Describe the deliverables the resource(s) will be responsible to complete as a result of their work on the project.

DATES REQUESTED

Starting: mm/dd/yyyy Ending: mm/dd/yyyy

HOURS OR % FTE

Provide the estimated number of hours or the percent of time the individual(s) will be need to be allocated to work on the project.

WORK LOCATION

Describe all of the locations the resource(s) will be expected to be located – if multiple locations, provide dates as they are know at the time of the request.

REPORTING STRUCTURE

Describe the reporting structure for the project and how the individual(s) will be expected to operate within this structure.

The Project Change Order Request – Version 1

Ah…the Project Manager’s best friend and worst enemy…the Change Order Request.  Projects have been halted and customers have been lost by presenting one of these fun documents.  As most of you aware, the change order request is created to cover a known gap between the work that must be done and the work that was planned (and usually priced).

The change request originates because the customer or project now needs something that wasn’t planned as part of the original project scope.  It usually comes with a price tag because of a change in the customer requirements.  However, it can be and should be used to document any deviation in scope – even if it doesn’t result in a price change for the project.  That way you have a baseline (the original SOW and requirements) for the project and documented changes to that baseline (the change request documents) as a paper trail to cover what work was actually performed on the project.  It can also be useful at the end of the project when you’re trying to justify the resource hours spent on the engagement.

I’m calling this one Version 1 because I have at least one more example that I plan to post soon.  Email me if you find this helpful and would like a Word doc version of it or send me your example to post if you want to share a different version to our readers.

PROJECT CHANGE ORDER REQUEST

[Save file name as: client name CHANGE ORDER yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

ISSUE TO BE ADDRESSED:

Describe the issue which the scope change will address

PROPOSED CHANGE IN SCOPE:

Describe the details of the scope change.

BENEFIT OF THE CHANGE IN SCOPE:

Describe the results of the scope change.

COST IMPACT OF THE CHANGE IN SCOPE:

The additional cost for this change will be $0. This will bring the total project cost to $0.

SCHEDULE IMPACT OF THE CHANGE IN SCOPE:

Project Schedule will be modified to a project completion date of month dd, yyyy.

ACCEPTANCE OR REJECTION OF THIS CHANGE ORDER:

The Client must accept or reject this Change Order within THREE (3) days of the date of this Change Order. The client’s failure to accept or reject within the prescribed period of time shall be deemed to be a rejection of this change order and Vendor shall continue with the project as if no change order had been issued.

Client hereby: Vendor hereby:

______ ACCEPTS the Change Order.

______ REJECTS the Change Order.

________________________________

Client Signature

______ ACCEPTS the Change Order.

______ REJECTS the Change Order.

________________________________

Vendor Signature

The Business Case Document

I’m trying to get on a roll providing our readers with some hopefully meaningful samples and templates of documents that may be needed on their projects.  These are templates that I created a few years ago – basically from information I think I probably found somewhere else…(isn’t that always the case?).

As I stated in The Project Charter Document article, if our readers have samples or templates they’d like to share, I’ll be more than happy to provide alternate versions of documents that I’m including here or examples of documents that I’m not covering…either will be much appreciated.  And I’m also very willing to send along Word doc versions of these templates to anyone who asks…just email me.

Here I am presenting a template for a Business Case Document.  If your customer is external, you may never see this or may never be involved with it.  If your customer is internal, it’s very possible that you’ll not only see it, you’ll be asked to help create it.  The key is to try to justify the existence of the project and the work to be performed.  The best way to do that is to show some cost/benefit analysis or return on investment (ROI).

This doesn’t have to be an extremely detailed document – leave that for the statement of work (SOW) and, of course, for requirements documents.  It does, however, need to speak very well to executive management and the key decision makers if there is to be any hope of kicking the project off.  Someone, somewhere, makes the final decision on whether or not to throw $$ and personnel resources at this effort and this document needs to convince them to approve that effort.

PROJECT BUSINESS CASE

[Save file name as: client name BUSINESS CASE yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

SOLUTION

Describe the proposed solution.

COST MODEL

ROI SUMMARY

Describe when the break-even point of the project will occur and expected annual revenue generated by the project.

PROJECT RISKS

Describe risks that may impact the cost/benefit of the project performance.

Another Take on the Statement of Work Document

In an attempt to continue to provide PM Tips readers with various templates and descriptions of key documents that are normally part of the project management process, I’d like to present this article with additional information on the always-critical Statement of Work (SOW) document. I’ve already provided much of my viewpoints on this extremely important piece of project information and it’s role in project inception and kickoff in the article “The Statement of Work.”

Here will present more information on this document as described by Carl Pritchard in his book “The Project Management Communications Toolkit.” Mr. Pritchard provides a discussion of the purpose and uses – from his point of view – of the SOW as well as a sample layout of the document.

Since many of the PM readers are looking for help in putting together good templates and understanding how some of these types of documents are laid out and used (especially for the newer PMs or individuals considering a PM career) I feel it is critical to provide our readers with as many examples of these tools as possible.

The Statement of Work

Purpose

The statement of work serves as a guideline of the agreements on performance between a purchasing organization and a seller of goods and/or services. It is frequently an attachment to a contract or a memorandum of understanding between two organizations. The SOW affirms how the purchasing organization wants the work to be performed and the context of that performance, including any specific management practices or protocols the contractor must follow.

Application

The SOW is normally used as an attachment to the contract or agreement and is one of the very earliest documents developed to clarify communications between organizations. As a component of the contract, it is frequently used to settle disputes over what work should or should not be included in a project. It establishes expectations for a variety of issues in the contract relationship, including (but not limited to) the following:

• Overall project scope
• Primary tasks and/or deliverables;
• Costs
• Reviews and reports
• Testing
• Support
• Performance requirements
• Period of performance
• Payments and invoicing

Because the SOW is normally an attachment to the contract or agreement, it is a primary reference document for the project manager throughout the life of the project.

Content

Because the SOW is most often developed by the organization requesting the project product or service, it normally reflects a functional, rather than technical, perspective. Although the customer may have technical expertise, the work they will identify in the SOW is frequently performance oriented or performance based.

An outline for a SOW might look like the following:

1.0 Project Scope and Objectives

This is often a rewrite (or a copy) of the scope statement for the project, providing a general, overall perspective on what the project is intended to accomplish.

2.0 Description of Deliverables/Services

If the project can be defined into the key components or elements of the deliverable or service, they should be defined in sufficient detail to guide the project organization on the buyer’s desired approach. This may include physical deliverables or reports, testing, and support components of the project. The description of deliverables and services is normally the single longest section of the statement of work.

3.0 Costs

In an internal or cost-reimbursement contract situation, a table for the anticipated costs by deliverable, month, quarter, or fiscal year may be provided. This would not be included in a firm fixed-price contract. This may include personnel and materials usage and rates, particularly in a time-and-materials contract.

4.0 Reviews and Reports

This is a detailed description of the regular reporting requirements associated with the project and the level of depth anticipated for those reports. It may include not only timing for the reports, but also the forms and formats required.

5.0 Testing

The testing component details what types of tests are considered mandatory and how and when they must be applied. This may include both formative (in-process) and summative (upon completion) evaluations.

6.0 Support

This component may describe support both during and immediately following the project. It should include some details about response times, type(s) of support (telephone, on site, e-mail, chat, and so forth), and what general areas may or may not be covered as a component of the support agreement.

7.0 Performance Requirements

If any specific organizational protocols must be followed, they should be included in the SOW. This might include security, team behavior, configuration management, risk management, and other managerial requirements of the purchasing organization.

8.0 Period of Performance

This should be a date-certain window of performance for the contract, from [date] to [date], with no work to be performed outside that window without a contract amendment.

9.0 Payment and Invoicing

This should provide specific guidance on any provisions for interim payment and identify any specific individuals responsible for ensuring payment in a timely fashion. It may also cross-reference any protocols for invoice submission.

Approaches

In some contracting organizations, the SOW is used as a place to incorporate any special contractual clauses that may not normally be embedded in the contract. If the organization does not normally have a “furnished property” clause or other clause that may directly affect performance, such clauses are sometimes included here. In other organizations, clauses that are nestled deep within the contract, but which are often overlooked, are repeated here for emphasis. The purpose of the SOW is to clarify what work is to be performed by the project organization. If those clauses have direct influence over how the work will be performed, their inclusion here may be appropriate.

Some organizations use SOWs even for internal projects. In such environments, the SOW is used to emphasize the contractual nature of the relationship among the functional managers who may be responsible for the effort.

Considerations

Project managers frequently use the SOW as virtually the sole arbiter of how they will move forward on the project. In some organizations, the SOW is the only customer-authored documentation the project manager ever sees. The project managers may not have access to the full contract, but they almost always have access to the statement of work. As the guiding force for project performance, regardless of legal consequence, the SOW is likely to be seen by the project organization as the final determinant of what the customer wants.