Response to SoW
Response to SoW
(OP)
What document would you use to show a customer what you are going to do in order to meet their statement of work (you've already been awarded the contract)?
So for example if they want a piece of test equipment mounted on a ship and you have done some analysis to show that an anti-vibration mount isn't needed then how to you convey this and your reasons to the customer so that they can accept the proposal. This would be one part of the response to the statement of work and there would be much more as the project evolved.
I'd like this to be a living document that the customer accepts as details are discussed and agreed.
What have you done to communicate and agree ongoing decisions that affect deliverable content/design?
So for example if they want a piece of test equipment mounted on a ship and you have done some analysis to show that an anti-vibration mount isn't needed then how to you convey this and your reasons to the customer so that they can accept the proposal. This would be one part of the response to the statement of work and there would be much more as the project evolved.
I'd like this to be a living document that the customer accepts as details are discussed and agreed.
What have you done to communicate and agree ongoing decisions that affect deliverable content/design?





RE: Response to SoW
If you haven't already, you can develop an Project Execution Plan. This would indicate what it is you are doing (or are going to do) and how you plan to do it, resources, personnel, software, etc. It is a living document that should be updated on a regular basis and developed based on the SOW.
Greg Lamberson, BS, MBA
Consultant - Upstream Energy
Website: www.oil-gas-consulting.com
RE: Response to SoW
I want to keep the project plan high level so I guess I could generate a document called a Work Plan which will specify what we plan to do in detail. In this will go details of what we intend to do.
Until now all details have been communicated and agreed bit by bit by email and there's no one document that defines to the customer what we plan to do. For example there may be an acceptance test and nowhere does it really state that there will be and what it will cover....eventually there will be an acceptance test plan but I want to capture everything we plan to do in one central document.
So the Project Plan specifies high level project control and the Work Plan specifies details of how we will meet the requirements?????
RE: Response to SoW
In this bid I would go through the SOW and indicate anywhere we wouldn't explicitly meet the SOW or clarify any areas that might be open to interpretation.
As to deliveries once the contract was agreed the SOW usually had a list of required documents including stress reports etc, this was sometimes called a Contract Data Requirement List and milestone payments were often attatched to certain documents.
In your case, dealing specifically with one issue I'd probably just prepare a simple report, it should be under some kind of configuration control ideally, or at least dated and signed like a letter. Some SOW define the format for such documents.
Beware, if their SOW explicitly stated to have a vibe mount, and you determine one isn't needed, depending how the contract is worded there may be financial implications.
KENAT, probably the least qualified checker you'll ever meet...
RE: Response to SoW
The projects I'm talking about are quite small....they can be handled by one Project Manager.....sometimes they don't even need a PM. They aren't large scale and would involve up to say 20 or so people.
Yes the SoW will usually define the deliverable documents but I'm thinking of a way of capturing all the 'little' things that are agreed with the customer as work progresses.
Sending individual documents is one way of doing this - I'd do this using a formal co-ordination memo to the customer. However there wouldn't be one overall document that would pull all of these together - I could still send individual reports but I'd like to reference these from my 'Work Plan' so that all technical details are captured in one place.
Futher there's a grey area during the early part of the project where details are agreed and these need to be put into the Work Plan and this could be done by the sales team and then handed over to others later.
Lastly.......quite a few of our customers don't define an SoW and they rely on memos and meetings to define the detail. In this case a Work Plan would define what they are getting....all WPs would be signed off by the customer (they might get the message that they should be writing an SoW).
RE: Response to SoW
In this report we would keep track of significant events as well as indicating progress toward milestones/achievements.
So I'd still have a detailed report on the vibe mount but it could be a line item in the quarterly report that no vibe mount was needed.
Note the report was updated each month, it wasn't a new report, so decisions made typically stayed in the report.
The projects I'm talking about were fairly small too, the biggest was only about $3-4 million most were much smaller. They were defense/aerospace projects.
Any help?
KENAT, probably the least qualified checker you'll ever meet...
RE: Response to SoW
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Response to SoW
Some comments on the last suggestions....
A monthly progress report would maybe work as it would summarise all the important decisions. It could reference the detailed reports so keeping eveything tied together.
An IMP and IMS would not give the detail I want - they would simply have line items and no descriptions of what was decided or details of analysis etc.
The progress report would work but I'll stick to my own suggestion for now of using a work plan which would have standard sections and so a lack of info in a section would flag up an action to complete the info. It would also be easier to read than a progress report although I could combine both - the progress report would show progress whereas the Work Plan would contain the details. I use an issues report so that would be similar - we could list issues that need to be addressed and then as they are addressed the details can be put into the Work Plan. Once the work plan is complete it would be more useful than the issues list although both would be of help.
RE: Response to SoW
Otherwise, what's the point of doing a plan that you don't follow, or doesn't correlate with your statement of work?
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Response to SoW
"Plan the work and work to the plan."
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Response to SoW
While you can plan, your plan must include planning for change.
RE: Response to SoW
I've decided to introduce internal SoW's but I'm going to call them Work Plans so as not to confuse with customer SoWs.
A change register comes after the SoW is agreed - what I'm trying to do is to capture all the stuff that has been agreed and defined with the customer so that when our sales guys are finished there's a proper definition of the work that needs to be done.
RE: Response to SoW
On my website is a document regarding how to put together a Construction Execution Plan. It's pretty exhaustive and really geared for large projects, but it might help.
If that doesn't - use the contact me page and I can send you something that might fit your needs a little better as far as a go-by.
Greg Lamberson, BS, MBA
Consultant - Upstream Energy
Website: www.oil-gas-consulting.com