We are a startup company where we work on software projects. To effectively manage our client's projects, I wonder what document we must ask the client to provide us before we both sign the contract. In other words, what document demonstrates the requirements and the needs of our client, which is filled out by the client, and then discuss whether we agree on that or reject working on this project?

Is the Scope of Work the document that the client can fill out before signing the contract?

  • 1
    Statement of work, statement of objectives, performance work statement. One of them. Commented Feb 26, 2023 at 18:20

4 Answers 4


A Contract is Anything to Which Two or More Parties Can Legally Agree

There's no singular answer to this question, and most of the question is out of scope for project management. It's more properly a business or legal question, and you should consult your company's lawyer about what's essential. However, there are certainly aspects to a contract that may impact the success or failure of a project, and you should certainly provide input about those elements to the contracting officer in an appropriate way.

What Parts of a Contract May Impact Project Planning

From a pragmatic project management standpoint, in the US you don't need anything project-specific for contracts in general. Master services agreements or partnership agreements are good examples of contracts where there's no need for specificity around specific deliverables.

For project work, you still need to consult your legal counsel, but in general you need things like:

  • A "Statement of Work" (SOW), which usually describes the deliverables, payment terms, and other factors related to a given set of deliverables.
  • Detailed payment topics such as time-and-materials, flat fee, or time- or milestone-based payments; triggers or deadlines for payments; methods of payment; and other more granular payment topics that are generally the domain of your finance and legal experts rather than the project manager, although the project management framework may certainly play a part in determining how these matters ought to be addressed.
  • Some form of a "Definition of Done" (DoD). In other words, how will the success or failure of the project or the quality or suitability of specific deliverables be determined?
  • A contractual agreement about how changes to scope, schedule, or budget will be handled.
  • Assumptions, caveats, and known risks for the project that might trigger changes to the SOW or the cost and payment structures.
  • How disagreements or termination of the contract will be handled.
  • How project risk will be divided between the companies.
  • Whatever else your legal advisors and senior executives think is necessary to protect your company's interests, and the company's successful execution of (or at least avoidance of non-payment for) the company's responsibilities as defined by the contract's terms.

None of these are strictly required, but they are certainly extremely common. It would be awfully difficult to commit to a contractual agreement to deliver a product or service without knowing what is expected, how much it will cost the buyer or the seller, or how other project-related matters will be handled.

Project Managers Aren't Usually Lawyers or Company Officers

The project manager certainly has a role to play in helping the company determine whether the proposed budget, schedule, and possibly the deliverables defined in a contract can be done with the resources that will be made available to the project, but the project manager generally lacks the training, expertise, or responsibility for contracting per se. I'd highly recommend not getting involved in the contracting process outside the scope of the project management discipline. Project managers are quite often held responsible for the success of a project without being fully empowered to exert meaningful delegated authority, so keep that firmly in mind.

Sticking your nose into the legal domain, or into a role generally reserved for company officers, will just make that organizationally unsupported accountability worse. In short, don't do that. Address yourself to the feasibility of successful project delivery based on the statement of work and other relevant items, but leave the contracting to the contract professionals.


Many times, clients do not know what they want, or they do not know how to explain what they want. So the normal approach is that the supplier works with the client to clarify all the details of the business:

  • technical requirements;
  • financial information;
  • schedules, milestones, deadlines;
  • standards to be followed / applied;
  • certifications / homologations (if applicable);
  • chart of responsibilities (who does what, when);
  • anything else.

In this work, several types of specialists would be involved:

  • technical specialists;
  • business analysts;
  • economists (sales, purchasing...);
  • lawyers;
  • project managers;
  • others, as needed.

All of these are baselined when everything is clarified, and become part of the contract. As you can imagine, there can be a lot of information, so mots likely there will be more than 1 document. How those documents are called, is of lesser importance. Different companies use different names.


The first document supplied by client to a service provider is often a Request for Proposal (RFP) or Request for Tender (RFT). The service providers, usually a selection of them, respond with their proposals and the client then decides which proposal to take up.

When it comes to signing a contract for software development (e.g. a service agreement and/or statement of work), if the agreement is to be on a time-and-materials basis then it's usually wise for both parties to leave requirements as undetailed and generic as possible. Agree a daily/hourly rate and an operating model and then work with the client to discover and develop what they need. Detailed requirements can rarely be determined in advance with any sufficient level of confidence to enter a legal contract.


I suggest to think also about the pricing model: Time&Material or Fixed Price or you name it. Here first example from internet: https://getbuilt.com/blog/fixed-vs-time-and-material-pricing/ This indicate what documents and content you and lawyers need to prepare.

Standard situation you need be always prepared for is that the customers expect more and push for getting more with the same price. That is why not only in-scope but also out-of-scope explanation is a good practice.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.