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.

Project Readiness: Ten Things You Must Do Before You Start

You’re handed a critical project to take and make your own. You finally get to go cradle to grave on it – you’re not just taking on someone else’s mistakes this time. What do you do to get started? Here’s a list of ten must-do’s – in no particular order – that will help ensure that you get the project off on the right foot.

1. Review the Statement of Work (SOW) – This is your starting point and the main document for the project to take off from. It’s loaded with assumptions, expectations, deliverables, milestones, rates, sometimes estimates, etc. It’s your starting point for putting together a decent draft project schedule, draft budget and forecast, and definitely the basis of most of the information you’ll want to cover in a kickoff session with the customer.

1. Identify the necessary resource skill sets for the project and request them – As early on as possible, identify what skills you’ll need for the project. Other projects and other project managers are likely in need of some of the same skilled resources and they’re usually in short supply, so put in formal requests as soon as possible. Don’t request them too early, because engaging a resource before it’s needed can blow your budget out of the water. The challenge is to onboard the necessary resources at just the right time so they’re fully and efficiently utilized.

1. Draft a project schedule – Sales may have provided you with a draft schedule that they worked out with the customer during the sales process. If they did, that may be a good starting point…depends on how competent and technically inclined your sales group is. If not, then start with the SOW and start plugging in timeframes, deliverables and key milestone dates noted in the document. Even if you do get a draft schedule from Sales, always cross check it with this document….ownership of the schedule is yours, not theirs.

1. Hold a knowledge transfer call with Sales – Conduct a call with the sales person or account manager that worked closely with the client to close the deal. They likely put together some of the SOW, drafted a schedule and rough budget and can give you insight on the customer and their key contacts. Those key contacts will likely be part of your customer team so any info you can get before going into the engagement puts you that far ahead to begin with.

1. Call the customer and introduce yourself – Before any formal face-to-face or project kickoff meeting, call the may contact or contacts and introduce yourself. You can maybe even think of a couple of high-level questions to ask them, but save the detailed questions and information for a later face-to-face meeting. This informal introduction call is not the time for that detail.

1. Do an initial forecast of resources for the length of the project – Depending on what kind of information is contained in the SOW, this may be a relatively easy task. Sales had to work out some detail in order to come up with a price for the customer. That’s your budget and it’s likely derived from estimated hours for each planned resource with prices attached to each. If that’s the case, then you’ve got a great start for a budget and forecast for the duration of the project. You’ll have to make calls based on deliverables and milestones on when to engage the resources and for how long, but you can cross check them with the estimated hours from Sales. This will be the basis for the budget and forecast that you’ll manage and share with both teams for the rest of the project.

1. Comprise a list of detailed questions for the customer – Following an initial call with the customer, discussions with Sales, and a review of the SOW, you’ll have some questions that need answers. These will be things you’ll need to know for input into the detailed schedule and how the customer may want certain things run on the project. Getting answers to these questions will help you put together information for your first detailed meeting with the customer which will likely be a formal project kickoff session.

1. Put together a first status report from what you know so far – Taking what you’ve learned so far from discussions and SOW reviews, you can put together your first status report for the customer and deliver it before the kickoff session. Include what you have so far for the draft schedule, budget and forecast. It will go a long ways in building initial confidence in you in the customer’s eyes because it will show that you’re in control and on top of things.

1. Put together a kickoff packet and schedule a face to face with the customer – Using something like PowerPoint, put together a formal presentation that you’ll use in the face-to-face kickoff session. Work with the customer to schedule a day-long session (or however long it needs to be based on your project’s needs) and make sure they have the right people attending (but not too many!). Explain to them that too many attendees lead to too many questions and eventually a kickoff meeting that is derailed and non-productive.

1. Conduct the kickoff session – Hold the formal kickoff session with the customer. Review the SOW, proposed team roles on both sides, deliverables, milestone dates, how and when meetings will be conducted, and discuss the change order process. Refrain from discussing budget items in this meeting unless the customer requests it – I’ve usually had the experience that customers only want certain people on their side privy to budget info.