SOW for staring a project?

Dora

It would depend on

a) if whatever you use communicates to the vendor what needs to be delivered clearly. The whole idea behind an SOW is to provide a clear and concise scope that needs to be delivered by a particular vendor.

b) agreement from the vendor. Obviously, they would only agree if they understand what needs to be delivered and what not.

Keep in mind that a 'lighter' SOW must mean unclear. You can remove details from a specific vendor SOW if those details are common to the project as a whole in which case you can just reference the project plan (or whatever relevant document)

Call it as you like but the important things are: 1-remember that product requirements must be used to define project requirements. 2-do not forget to take a look to Barry Bohem´s Cone of Uncertainty to stay clear about the amount of information (product requirements) and its ambiguity will impact all you define for the project (project requirements). 3-is critical to agree the project change management process, which will be the accountability and responsabilities for each part. 4-define as clear as you can the roles and responsabilities and assign a person to each one. 5-all your work must be driven for risk identification as much as you can because the situation I described in point 1.

Dora,
The need to start a project when there are some significant uncertainty in the SOW is not uncommon. It simply means you are taking on risk, and without risk there would be no need for PMs. The good news is that you already know something is driving your need to start immediately. This is better than finding out 2 months in, that you are now 2 months late.

Developing a SOW usually stars with a high level plan, and detail is added as you develop the WBS. The high level SOW is essential to define your scope and understand the various pieces you will need to integrate. Examining the high level SOW, you can put some rough estimates together as to when those activities need to occur, allowing you to develop a rough schedule and priorities.

In addition to the high level plan, you already know at least one significant schedule risk which is driving your early start date. To mitigate that risk, I would put as much detail as possible into whatever it is on the critical path you have identified that is driving that early start. The ambiguity in other parts of the SOW drives risk that you will need to alter the critical path as new information becomes known, but that is better than not having a project at all.

Many things would influence the level of detail required.

Comment by Anton and Sergio still apply. Here are a few questions that could influence the level of detail, not saying it is a good practice to have a limited SOW.

Is the client internal?
Is it a client we have done many projects with?
How was project closure, if it is a known client?
What is in the contract? in the RFP?

thanks pretty clear the point is we only have 4 months to deliver the first product and we are not going to have a detailsscope analysis to sign the sow