Nov 29, 2017
Would anyone tell a contractor to build a house and then walk away to let him do it as he pleases? Probably not. Most people would at the very least specify the how, where, when, and cost. Professional projects are no different.
Then comes the question of what is sow (statement of work) of any given project or assignment. Few of us get along that SOW is same as the scope of work. The statement of work (SOW) in an RFP or RFQ defines a project’s goals, deliverables and performance criteria. A scope of work (SOW), included in the statement of work, describes the specific tasks the contractor will perform to meet objectives. In a freelance marketplace for telecom engineers, Statement of Work (SOW) holds of paramount importance so as to comprehend better before initiation.
The scope of Work (SOW) is a tool that allows the business of all sizes, calibers, and niches from telecommunications to construction to communicate such vital business details with employees, vendors, contractors, and freelance workers.
Statement of work and scope of work, both commonly abbreviated as SOW, are often confused, interchanged terms. And, as straightforward as each sound, they’re often anything but easy to write. Make it too vague and broad and it leaves room for interpretation error; make it too convoluted with detail and it leaves room for the reader to get confused and distracted. Either case can lead to fiscal, safety, efficiency, and legal woes, especially when freelance workers are involved.
It’s not uncommon to see both terms abbreviated as SOW, but they’re actually two different entities.
The statement of work is a document used by project managers to broadly describe the work to be completed, responsibilities, and expectations within a particular project. It’s a commonplace tool for management of vendor and freelance work on a project.
The scope of work is an element within that statement which more narrowly defines what work is to be done by the employees or contractor.
Think of it like the difference between retinol and vitamin A. Technically, they’re different compounds, but they’re used interchangeably because consumed vitamin A becomes retinol in the body. The scope is consumed within the statement and becomes one in same.
The SOW as a whole is a planning tool that allows project managers to develop performance-based work relationships with vendors because all aspects of performance and subsequent assessment are laid out up front.
It can be a standalone process OR written in conjunction with an RFP, or request for proposal, asking the freelancer to respond with a proposal.
What Key Points Should Be Included in Any Statement?
The objective, or scope statement, clearly identifies the project’s objective and purpose. Think about how the project was initiated, who it benefits, what purpose it serves, why it’s needed, and when it needs to be ready for utilization? Asking all the pertinent who, what, when, and how questions can help determine each objective goal and end result in order to formulate a comprehensive scope statement. This will define what work is to be done and by whom. It will also define what constitutes success and failure of the project.
Deliverables are the results that must be accomplished through work. They can be categorized as a whole to be completed by the end of the project OR in phases to be completed by individual deadlines. It can also be addressed as a certain percentage completion by certain dates. Each deliverable should clearly state what is specifically due, when it’s due, by whom it’s due, and the quality acceptable upon delivery. Be sure to keep the performance deliveries realistic. Keep deadlines in universally measurable values, such as “mid-January” vs “the first part of the year,” which could be argued is any time before June starts ‘mid-year.’
This step defines each work role within the project. It can do this by class, tittle, and/or group of employees. It can also/or group similar tasks by time frame.
However, it’s organized, the most important element is that each worker takes away a clear definition on what their role is within the job.
Tasks should indicate performance requirements and any policy a worker must adhere to in order to comply.
Often times a work breakdown structure (WBS) is used in conjunction here. It breaks down work into precise packages based on who and what type of work needs to be done during specific time frames. Combining the two helps to keep workers on task, providing clarity that anything not listed on the WBS falls outside the scope of the project and shouldn’t be done.
This section should give a start and end date to the entire project and list any scheduling considerations that would stop work or otherwise delay the project.
The main and any secondary locations should be specified. Any procedures that would require specialized entry, exit, or boundaries should be labeled.
List any additional labor, resources, and materials necessary for the project and for classes of workers. A good example is tools. What tools are needed? Who will need them? When will they need them? Who is responsible for providing them? Computer access, personal protective equipment, sub-contractor use, etc are all examples of common resources various types of projects might require.
Detail the pricing, pricing schedule, and who is responsible for what cost and when. Are there any contingencies? If so, what and how do they apply. A target cost for each phase and the completed project is also standard.
How much manpower will be needed during each phase of the project and what skills should they have. Targets such as scheduling and overtime should be addressed. So, contractors have the power to hire out subcontractors? If so, are there any stipulations?
List all reporting requirements and detail what, when, and how the reporting will take place. Some common methods are periodic inspection and random sampling of deliverables. Some businesses tie this into payment by offering a percent paid upon inspection of each deliverable and later percentages paid upon inspecting how all the deliverables function as a unit.
Clearly state any terms and conditions, such as IP rights, proprietary info, non-disclosures, and confidentiality agreements.
While the scope statement defines the parameters of the project, there may be certain exclusions that need to be specifically addressed as a ‘don’t do this’ in particular. A telecommunications freelancer should never use a certain programming feature in establishing voice and data networks, for example. This is the place to put any high-priority exclusions in plain writing.
Any post-project need should also be addressed. For example, will you need follow up IT support and what will be the terms? Is a warranty mandated? Will contractors train in-house employees on operation?
These key points should each be concisely detailed as it applies to the project.
In real terms, having a comprehensive SOW allows vendors, contractors, employees, and freelance workers to understand a project’s requirements and parameters before work starts. Project managers will see that work is more efficient, project evaluations and negotiations are kept to a minimum, and project changes are less frequent.
Having a written plan of action that includes all parameters of a project keeps costly time delays and legal disputes down for both sides.
Composing a SOW usually falls on the shoulders of project management to complete.
It can be a daunting task due to the fact there are often so many variables and projected expectations to consider at the start, during, and after a potential project. Throw in that the language needs to be clear and concise, and the writer really must be on top of their game.
How a detail is written is just as important as the detail itself. In closing, here are some quick SOW language tips to help ensure clarity on both the worker’s and writer’s side of a SOW:
• Write in an active voice, using strong nouns and verbs. “All freelance telecommunications staff must arrive on-site by 8 a.m.”
• Use ‘working’ words (analyze, evaluate, examine, generate) as opposed to lay language (look at, think about, do.)
• Avoid unenforceable language and terms left open to interpretation – “The contractor *may* wear PPE.” May implies the worker has a choice to wear it. “All work is *subject to approval. *” Approval from whom and by what standard? It’s an unenforceable edict.
• Never use etc, so forth, or any other open-ended statement.
• Check for grammar. It’s the difference between knowing your crap and knowing you’re crap.
• Use unambiguous language. Anyone from management and freelancers to a judge should be able to look at each sentence and understand its meaning and purpose.
The article is written based on professional experience and the best practices promoted by FieldEngineer (FE). It bridges the gap between telecom network engineers and service providers by connecting them to a single platform.
Engage skilled engineers anytime, anywhere!