Response to SoW 1

[stockdam]

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?

 

[GregLamberson]

stockdam

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:

http://www.oil-gas-consulting.com

 

[stockdam]

I use a Project Plan which defines how the project will be managed but it doesn't include technical detail.

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?????

 

[KENAT]

I used to have to prepare a formal bid, but this was before contract was awarded.

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...

 

[stockdam]

Firstly to clarify one thing......

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).

 

[KENAT]

Just remembered. Some of our projects called for a quarterly progress report.

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...

 

[IRstuff]

All our projects require both an integrated master plan (IMP) and an integrated master schedule (IMS), which chronologically lists tasks and milestones.

TTFN

FAQ731-376

 

[stockdam]

You've all been very helpful and I think I've clarified in my head what I need.

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.

 

[IRstuff]

Everything thing has to go together. Our IMS' go down to roughly <100-hr task granularity. Your internal statement of work for bidding should correspond to and provide the details for those task items.

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

 

[IRstuff]

While trite, the old adage still holds true:

"Plan the work and work to the plan."

TTFN

FAQ731-376

 

[sdz]

It sounds like you need a Change Register. All variations should be documented, costed, and agreed to by the Principal in writing before the work is done.

While you can plan, your plan must include planning for change.

 

[stockdam]

A comment on Irstuff's post........we don't have an internal statement of work and that's where the problems stem from. Our sales team usually use emails and meetings to define the work but they don't produce a statement of work. It's ok when our customers are organised and they give us an SOW but we don't produce an internal one - that's really what I was getting at.....I've inhereted the way it was done and am now trying to improve things slowly.

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.

 

[GregLamberson]

stockdam

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:

http://www.oil-gas-consulting.com