What Goes into a Good Statement of Work
Posted by Brad EgelandThe post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner. Please visit their site for more information.
This article is based on information from one of my favorite PM books – Eric Verzuh’s book entitled “The Portable MBA in Project Management.”
The statement of work (SOW) basically kicks off the project management process and is meant to document the goals and constraints of a project. However, it cannot and certainly should not attempt to document every agreement about the project. There are other project and project management documents for this purpose – requirements, specifications, customer acceptance tests, and also you basic output of agreements and notes from kicking off the project with the customer. The SOW should record the goals and constraints for managing the project. While that can contain a wide range of information, the minimum content listed here gives you an idea of what makes up a good, useable SOW:
- Purpose statement: A clear description of why we are doing this project.
- Scope statement: A description of the major activities of the project in such a way that it will be absolutely clear if extra work is added later on.
- Deliverables: A list of outputs the project will produce, including intermediate deliverables, end deliverables, and deliverables related to project management.
- Cost and schedule estimates: In addition to a budget and a deadline, a description of how flexible the budget is and the rationale behind the deadline.
- Project objectives: The specific, measurable goals of the project.
- Chain of command: An organization chart that spells out who makes decisions and to which superior problems will be reported. It is often a good idea to include the organization chart of the customer, as well.
The SOW is a tool for managing expectations and dealing with change. When disagreements arise after the project has started, they can sometimes be solved by simply reviewing the original SOW. However, it is also true that the original agreements and assumptions may change during the course of a project. In this case, all stakeholders must understand and agree to these changes, and the project manager must write them into the SOW or track them through other project management processes such as change orders. The SOW that remains at the end of the project may be very different from the original document. The amount of this difference is not important; what is important is that everyone has been kept up to date and has agreed to the changes.
The Challenge of Project Communication
Posted by Brad EgelandWe’ve all heard the clichés about communication. But putting the ideas into practice is often a lot harder than applying the theories. This is even truer for project management than for departmental management.
For the purposes of this article, I’m looking at department managers who take on the role of project managers for one-off projects or for organizations that regularly rely on department managers to act in the role of project manager, because not all PMs have the ‘luxury’ of focusing solely on project management tasks. Some are temporarily thrust into the PM role while their primary responsibilities – and ultimately skill set – is outside the role of the project manager. We’ll look at the communication challenges faced in these types of situations.
The Communication Challenge
While managing your department, you’re in constant contact with your staff. Their tasks are well defined and recurring. Your people are focused on performance, and their careers depend on how well they execute their tasks. A project, by comparison, is often seen as an intrusion, a departure from the normal routine—even when it’s “normal” to disrupt that routine with a series of projects.
In addition to the manager-team dynamics, you must contend with communication on three other levels:
- The assignment. The executive (or committee) that first assigned the project to you may not agree with your idea of what the project should achieve; or he may change his mind about the outcome wihtout letting you know.
- Other departments. The managers of other departments have their own priorities and may resist your schedule. This usually applies in two situations: when members of their department are on your team or when you depend on that department to supply certain information.
- Outside resources. Your project may depend on help or information from “outside” resources—companies or individuals not part of the organization. These include other divisions, subsidiaries, or offices; a vendor or separate corporation; or a consultant.
Your budget and schedule are your best communication tools. They are useful in communicating with both your team members and outside resources. Each can be used in a number of ways.
The Budget as a Communication Tool
The budget defines the company’s financial commitment, and is used to ensure that project expenses are kept in line. If variances do occur, they often anticipate a scheduling problem as well.
The budget also measures the degree of risk involved with your project. Any change in the company is accompanied by risk, and when time and money are spent, the decision to go ahead is based on a judgment of risk. Management will proceed with the project if it is convinced that the risk is acceptable and that future profit potential justifies that risk. So, for example, when you propose a project, you should communicate in terms of risk and likely reward. Approval will be granted as long as you can convince management that there’s a good chance that future profits will recapture this investment within a reasonable period of time.
The Schedule as a Communication Tool
The schedule defines the project, and, as long as you share it with management, it is a useful tool for ensuring that your definition conforms to theirs. When it’s broken down into phases, with deadlines tied to the final result, management has the opportunity to validate your direction, and you can ensure that your understanding of the project’s goals is correct. At this early stage, you can define exactly what the project should achieve.
You also need to use the schedule during the later phases of your project in conjunction with review meetings to ensure (1) that you are on the right course and (2) that management’s desired outcome has not changed.
Finally, the schedule improves communication with your team, and helps avoid delays. By identifying weak links and by communicating with other department managers and outside resources, you will avoid unexpected problems.
Working with Other Department Managers
For relatively simple short-term projects that are executed strictly within a single department, you, as department manager, have direct control over the time commitments and priorities of each team member.
Because you are aware of your department’s deadlines and workload variations, you can build your schedule around the workload and adjust it as needed. You can also balance departmental and project demands on the basis of your knowledge of each and the scheduling flexibility and control you’re able to exercise.
As the scope of your project grows, your task assumes a greater dimension, and you will begin to work with people from other departments. This is where your communication skills are tested.
A common complaint often heard from other managers is, “You didn’t tell me in time,” regardless of whether problems arise because of deadlines, the use of an employee’s time, or conflicts in commitment. But you can solve most of the problems you will encounter in working with other departments by remembering this key point:
Keep other department managers informed at all times: before and during the project.
By applying a few basic rules for communication between departments, you will be able to defuse the problems that beset all managers at one time or another: territorial motives, power struggles, and—in cases where communication breaks down completely—outright refusal to cooperate. Most of the time, the breakdown of cooperation arises not from a political or personality problem but from a failure in the communication link—especially when you have made the effort to communicate, but only once. People need periodic reminding, so don’t assume that a single message will be remembered.
The Project Change Order Request – Version 2
Posted by Brad EgelandAs promised – another version of the love-hate Change Order Request. This is a cut/paste from a Word doc template that I would be happy to share. The Word doc version looks much better, but this at least gives you an idea of the content that is being captured here for customer approval.
The main concept is to capture as much information about the proposed scope change as possible and estimate each task effort that it’s going to take to get there. Once that effort and budget info is captured here, that information can easily be rolled into the project schedule to show your customer how the change order request is going to affect the overall project timeline.
I’ve been using this version – or at least some variation of it – for most of the past three years on projects and it’s served me very well. The change order request is always a delicate subject for both the project manager and the customer so handling it carefully and in the greatest detail possible is critical to good decision-making and for on-going customer satisfaction since it usually results in the customer paying more on the project (but not always because even things that decrease the project scope and cost should be documented using this same process….it affects the project, too!).
Again, if you want a Word doc version of the template let me know. And if you have a version you can share, I’d like to see it and share it with our PM Tips readers as well.
Change Request Initiation |
|||
|
Change Title |
|
Change Request #: |
|
|
Date Submitted: |
|
Date Required by: |
|
|
Related Requirement(s): |
|
Related Issue(s): |
|
|
Submitted by: |
|
Contact Phone: |
|
|
Description: |
|
||
|
Attachment(s): |
|
||
|
Reason: |
|
||
|
|
|
||
Technical Evaluation |
|||
|
Technical Consultant: |
|
Date: |
|
|
Conclusions: |
|
||
|
Project Manager: |
|
Date: |
|
|
Conclusions |
|
||
Budget/Project Impact Evaluation |
|||||
|
Project Manager: |
|
Date: |
|
||
|
Change of Scope? |
Y/N |
Description: |
|
||
|
Technical Consultant: |
|
Date: |
|
||
|
Summary of Work Effort Change: |
|
||||
|
List of New or Changed Tasks – Projected |
||||||
|
Task ID |
New? |
Description |
Budget Hours |
Est. Hours |
Total Chg |
Cost Change |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Totals |
|
|
|
|
||
Risk Evaluation |
||
|
# |
Description |
Risk Resolution Strategy |
|
|
|
|
|
|
|
|
|
|
|
|
Determination |
||||||||
|
|
||||||||
|
Approved: |
|
Rejected: |
|
Deferred: |
|
|
||
|
|
||||||||
|
Reason: |
|
|||||||
|
TRIRIGA Project Manager: |
|
|||||||
|
Signature: |
|
Date: |
|
|||||
|
Customer Authorized Representative: |
|
|||||||
|
Signature: |
|
Date: |
|
|||||
Execution |
|||
|
Assigned to: |
|
Target Completion Date: |
|
|
Priority: |
|
||
|
Instructions: |
|
||
|
Attachment(s): |
|
||
|
Completed by: |
|
Actual Completion Date: |
|
Acceptance |
|||||||||
|
|
|||||||||
|
List of New or Changed Tasks – Actual |
|||||||||
|
Task ID |
New? |
Description |
Budget Hours |
Est. Hours |
Total Chg |
Cost Change |
|||
|
1 |
|
|
|
|
|
|
|||
|
2 |
|
|
|
|
|
|
|||
|
3 |
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|||
|
Totals |
|
|
|
|
|||||
|
Customer Authorized Representative: |
|
||||||||
|
Signature: |
|
Date: |
|
||||||
The Project Procurement Plan
Posted by Brad EgelandHere is another template who’s usability really depends upon the given project and the customer. This one is the Project Procurement Plan. It’s great for larger projects and for government projects and it is designed to be produced at the beginning of the project along with documents like the Risk Management Plan and the Project Communication Plan.
The idea is that you lay out the formal process of how you will go about procuring things for the project throughout the engagement. In this document, you identify formal processes for vendor selection, customer/vendor responsibilities and contact info, how the selected vendor will be managed as the procurement is taking place and who’s responsibility that will be, etc. Laying these formal processes out in advance will definitely help the engagement move along more smoothly and will help you to address this issues as the arise.
PROJECT PROCUREMENT PLAN
[Save file name as: client name PROCUREMENT PLAN yyyymmdd]
|
Client Name: |
|
Title: |
|
|
Project: |
|
Date: |
|
|
Project #: |
|
Version: |
Template 1.2 / Document 1.0 |
![]()
PROJECT DESCRIPTION
Provide a brief description of the project objectives and overall performance of the work to be performed.
PROCUREMENT DEFINITION
Describe, in specific terms, what items will be procured and under what conditions.
CONTRACT RESPONSIBILITY
Provide list of project stakeholders who are authorized to enter into contract agreements of purchase for the Project.
Name: |
Phone: |
Responsibility: |
|
|
|
|
|
|
|
|
|
|
|
|
VENDOR SELECTION
Describe what steps the project team will take to select a vendor (e.g. RFI, RFP)
DECISION CRITERIA
Describe any known risks which will need to be addressed with the project statement of work.
CONTRACT TYPE
Document which types of contracts will be used and what actions need to be taken to initiate procurement.
CONTRACT STANDARDS
Provide the standards for documentation that will need to be initiated and maintained for each contract.
VENDOR MANAGEMENT
Describe what steps the project team will take to ensure that the vendor provides all of the products and/or services (and only the products and/or services) that were agreed upon, and that appropriate levels of quality are maintained..
ASSUMPTIONS
Describe the initial assumptions under which the project will be to perform.
CONTRAINTS
Describe the scope/cost/ time/resource constraints under which the project will be to perform.
IDENTIFIED RISKS
Describe any known risks which will need to be addressed.
APPROVAL
IN WITNESS WHEREOF, the parties have agreed to the Procurement Plan on the date or dates indicated below.
CLIENT APPROVAL
________________________________
Client Signature
VENDOR APPROVAL
_________________________________
Vendor Signature
Strategies for Managing a Mobile Team
Posted by Brad EgelandI ran across a great document put together by Terrence Gargiulo for Makingstories.net. Mr. Gargiulo discusses what he feels are the top ten strategies for managing mobile workers. His full document is a very good read because he also discusses things such as risks and issues to consider when managing mobile workers. You can access his full document here.
I’m sharing this here because so many times as project managers we are overseeing the work of a very geographically dispersed team. In the past three years I’ve only managed one project with a team that I could see on a daily basis. Dozens of others involved remote workers all around the country.
Here are Mr. Gargiulo’s Top 10 Strategies for Managers of Mobile Workers as described in his document.
Top 10 Strategies for Managers of Mobile Workers
1. Focus on building relationships
You are now in the business of managing relationships. Once a quarter audit your time. How much time are you spending engaged in activities meant to foster stronger relationships with your mobile employees? Rate each relationship on a scale of 1 to 10 where 1 is weak and 10 is very strong. Craft a strategy for continuing to develop your strong ones and triage the weak ones. Ask yourself why they are weak and what you can learn from them. Avoid finger pointing and hold up the mirror to reflect on your own opportunities for improvement. Extreme cases of under-performance do not warrant time or effort. These however are few and far between.
2. Streamline communications
Consolidate and prioritize communications. Use email and IM (instant message), texting, blogging, threaded discussions, etc. for relationship-driven communications (i.e., staying in touch and being personal). Communications of an important nature should be cohesive and never delivered in fragmentary pieces that have to be cobbled together by the receiver. Mutually assess the communication preferences of yourself and your team members to develop a communication plan. Avoid assumptions and revisit your plan on a regularly basis especially when the nature of the work is about to change.
3. Incorporate less didatic forms of communications
Determining the right amount of detail and when to provide detail is an ongoing responsibility of a manager with a mobile worker. As a general rule, less is more. This leaves bandwidth for the times when lengthy, explicit instructions and information are essential for the work at hand. Try working with more story-based forms of communications. Sharing tidbits from the field and office in the form of stories, anecdotes, case studies (use cases), jokes, innocent productive gossip, and even metaphors will relay context, encode key pieces of information, and give mobile workers a sense of inclusion.
4. Spend more time listening
Obvious, but counterintuitive. When you are out of easy reach and you are tasked with managing the performance of others it’s easy to get sucked into the trap of needing to transmit lots of information. In most cases the opposite is what is most productive. Make listening a priority. This is the hardest and most tiring aspect of managing others. It is also the single most important thing you can do accelerate the development of strong relationships. Listening is not enough. Keep an open mind. Be present and try to enter the perspective of the speaker. This will help you ask effective questions and identify what direction to go with your own needs and agenda. You’ll be surprised at what emerges.
5. Let mobile workers define communication and reporting practices they want to follow
Structure is critical. Adopt rules of engagement that place people at the center of their own decisions. Managers provide the boundaries and constraints but let employees define the working and communication styles, tools, and processes that will help them perform at the best. Set expectations on two fronts. First, treat these employees’ defined practices as privileges that can and will be modified if key performance metrics are not hit. Second, let employees know there will be times when a projects or work require less flexible, employee-driven communication and reporting practices.
6. Manage deliverables, not activities
Lots of project-oriented work is well suited to mobile workers. Even roles that are more task driven can be effectively managed if they are broken into deliverables. For mobile workers this may mean collapsing some of the activities of a business process or workflow that had manual checkpoints and controls associated with them into deliverables. Automation where possible can be used or batching activities into larger groups can transform task oriented jobs into deliverables. Realize that there can be many facets of people’s jobs that need to be adjusted to accommodate a mobile work style.
7. Engage in more frequent and informal performance management activities
When you manage mobile workers, relationships are at the heart of your job. Performance management does not need to be a loathsome, “administrivia” obligation. Designing some unstructured, informal ongoing dialogs with mobile employees about their performance goals and personal development plans is a great way to strengthen communications, and shows an active interest in employees and relationships. This might look and feel very different from one employee to the next. This is another tangible way managers can adapt their style to match the needs and preferences of employees. It works best when the performance management conversation flows in both directions.
8. Give complete trust until given a concrete behavioral reason to do otherwise
According to a recent survey conduct by HR.com and ic4p, listening and trust are the two most important factors to virtual and remote teams. Without trust, relationships are bankrupt. Abuses of trust can always be found but these occur in spite of whatever systems we put in place. Mobile workers thrive when managers give them complete trust. In some respects managers of mobile workers have no other choice. Use trust to create strong relationships. When some concrete behavior and not just someone else’s word of mouth shows that trust has been violated, then take it away, but not until then.
9. Use adaptive management styles tailored to individual workers
Every employee is different. Mobile workers make it easier for managers to take a more personalized approach in how they work and interact with members of their team. It takes more work and effort on a manager’s part but the results can be phenomenal. Understanding what enables each employee to perform at his or her best is the most important responsibility of a manager.
10. Leverage technology
Technology drives and supports managing mobile workers. Using technology well is not as simple as it appears. Standard models of communication and transaction should not always be mapped in a simple one-to-one way. Communication and collaboration technologies offer new and exciting models. These need to be purposely exploited in order for organizations to realize the full extent of benefits these wonderful new capabilities and features offer.
Beyond email, IM and phone, Web conferencing plays a key role in virtual team enablement. Take an inventory of “stuff” you need to collaborate on with your virtual team. If the list includes Word docs, spreadsheets, software applications, or anything else on your desktop, Web conferencing will be critical for collaborating in real time. You’re projects will lag if you can’t be on the same page with mobile workers.
