Project Contracts - the Essentials for Project success
This article is part of my Project Management Fundamentals Series. Where I will share the tools, knowledge and methods used by Project Managers globally.
The Essentials of Contracts for Projects
Define Expectations
Design Objectives
Document Plans
Are you a small business owner or Project Management freelancer? Maybe you work for an organization as a Project Manager or Project Sponsor. In all of these cases: If you have a client, you will need a contract.
I am not a lawyer. Contract laws, legal wording, requirements, and terms can differ depending on where you live or what you are contracting to do. So if you need a contract, you will need to work with a legal professional such as a lawyer or a notary.
While I am not offering legal advice, I have a structured way of thinking about project contracts. Ensuring Contracts include not only legal requirements, terms, and conditions but also project requirements. Contracts should follow the 80/20 rule. 80% of contract content should focus on the important aspects of a project - those Critical Success Factors, Governance, and Measurements that ensure project success.
I will summarize:
How Project payment sets the context of the Contract
What topics you may want to cover in the Contract, and
How to set expectations by using schedules and exhibits
I have years of experience in negotiating contracts and project plans with customers big and small. If you read my blog on Project Failures, you will know that the wrong Contract (or a poorly designed contract) can cause a project to fail. When:
the financial arrangement does not fit the project goals or Governance
the project timeline or staffing does not meet the needs workload
the risks and uncertainties of the outcomes are not addressed and documented
Projects can be set up for failure. It is easy during contracting to "want to get on with it," but contracting is where the Project starts. Use this period of optimism and goodwill to get things right. To help you do this, I offer detailed tips and ideas to use as input to creating a contract that meets the specific needs of your Project: to set the Project up for success, manage expectations, and mitigate risks—the goal of a good contract, making a successful outcome for all parties.
The Essentials to Project Contract design
Before working on the Contract, start with the Project: Make sure you have a Project Charter, work plan, and staffing plan (see the Project Workbook's blog to find an example of these documents). What are the "must-haves," the "nice to haves," and what risks need to be mitigated?
Be prepared. Draft of the Contract points you find critical. You may also have a draft contract to use as a starting document. A draft Contract can save time and money by allowing you to "get an agreement" sooner so the Project can get started.
Start the discussions with the project requirements and goals. When you start your review of the Contract, share your draft content documents with your contract stakeholders. Getting on the same page from the start can help all parties understand the key points driving the contract requirements.
Show you have the right intentions and are professional by being prepared and have:
Defined Project documents are ready
Designed Project plans with the key requirements
Drafted Contract product success criteria ready to review and share with stakeholders
Doing this work up front should make the rest of the process go more quickly and help you to remain focused. The draft document, by default, sets the stage for discussions.
“The beginning of wisdom is to define”
1. Define the What
What are you contracting? Services, Results, Outcomes?
A brief review of the options:
Hourly Services: Services are generally time and materials, meaning payment is based on hours worked at a fixed price per hour. This may be satisfactory for unspecified work or the initial project phases. However, in 2021, most Customers want results and will likely ask for more result-based pricing.
Hourly Example: 160 hours a month at a rate of 100.00 an hour for six months, as a Project, Lead to manage an app build project, with a specific level of responsibility and authority, normally minimal risk.).
Result-based Services: Services and responsible are more specific and measurable. Supplier risks are higher but so are the rewards. You will want to make the Contract SMART and be clear about your responsibility to the Project, process, staff, and outcomes. Your authority needs to match your responsibility. The outcome needs to be realistic to meet a timeframe you and the Customer agree to based on the scope, staff, skills, and uncertainty involved.
Result Example: Deliver an MVP Student App starting March 1, ending December 1. Scope includes testing. Go live is determined by successful user group testing. Authority and responsibility will be higher, as will the risk associated with the work, decisions, and outcomes.
Outcome-based Service: Outcomes go beyond initial results. It looks for the result of the result. Metrics for performance are generally tied to this kind of Contract.
Outcome Example: Deliver an MVP Student App to be launched by December 1. This app should meet student needs and attract a 75% adoption rate by all students enrolled in the 2022 School year.
Fixed Price Service: Any of the above formats can be treated as a fixed price by capping the total cost or price. Fixed price also often has a schedule of payments based on milestones. Because of this, it creates a greater risk to the services supplier and greater comfort to the Customer. However, Fixed Price is a tool to use
when the risks and issues likely to face a project are well known, and
when the responsibility of the supplier equals their authority
Ensure that fixed price is fit for purpose. You need are signing up for Project responsibility, so make sure your authority is equal to the level of responsibility of the fixed price outcome. If you are working at a fixed price, but the Customer still wants to lead and make the key decisions, you will likely have issues from the outset.
2. Define the Who
Who are the contracting parties? Are there more than one? What legal entities are involved, and where are the contracting sites? Let’s Review:
As mentioned above, create exhibits to support the plans. This may start with the Project Charter and include key aspects of the project team.
Name the key project team members or roles and effort (hours) needed. Document the project team and staffing conditions include RACI or Staffing hour plans if possible.
Define who and how the team will be hired and managed. Note required skills and capabilities. Document how the Project will address skill gaps. Who will have the authority to allocate work, team organization, and project staffing (hiring and replacement of team staff)?
Document who the decision makers are. If this authority is not with you, who is it with? How close are they to the Project (the Customer often has client PMs or Project Owners who own at least some of these tasks)?
If you don't have authority over staffing, think about how this impacts your ability to manage the Project. This may drive the decision on the contracting "What" decisions noted above.
If team members are customer employees, you will need to work closely with the Customer and HR to define and design the way of working, roles, and rules of working with employees versus 'contracted' staff.
Detail Project Governance in all Contracts. Be clear about the Governance of the Project. Who will make the project leadership decisions, oversee staff, define strategy, scope, and confirm change requests? If this is more than one person, document their role, responsibilities, and skill level. If you have a contract for Results or Outcomes, document who you report to and your ability to veto or limit project risks.
3. Define the How
What project management processes and systems will be used? Will hard or software be needed to run the project or produce the final product?
If technology is key to the Project's success, ensure it is a known product and is accessible. If using new technology, look to limit the outcome risks, especially if other parts of the Customer's organization are required to act on behalf of the Project. Their timelines and workload may impact the Project's ability to meet deadlines.
To avoid risk when there are too many unknowns, you may want to contract separately for the "define" or exploration phase based on Hourly service. If desired to move to a Results Service contract, the Define phase can mitigate risks. With the project scope, plans, and risks better defined, a Results Services contract to be created for the next phases of work.
If in doubt, write it out.
Scope of work planned - especially if the Project is a "start to finish" project, including user process review, training, testing documentation. If an MVP (minimal viable product), what is the requirement for the MVP. What is out of scope? Note the logical components that may be assumed to be in scope and, if out of scope, document it.
Project Plans - Your project plan should cover the how as well as the what. By including these high-level documents as exhibits or schedules named in your Contract, you will be setting expectations. To assist with the need to address changes that may come up from these high-level plans, be sure to document change control procedures in the Contract.
Milestones - do milestones have to be signed off or otherwise follow required processes? If so, what are they, and is there a schedule or other documentation you can review before finalizing the Contract.
Staff Allocation - as discussed above, understand the staffing plan. But also discuss the scope and involvement of user groups. Will you need user involvement, access, and approval? Address the impact of access, onboarding, and oversight of staff and users needed for the full project lifecycle
Technology - define technology needed for running the Project and for the product (if any). Ensure you are familiar with the technology or have staff who are. Document which configuration or version of the technology will be used in the Project. Confirm how the technology will be accessed, managed, and maintain.
Intellectual Property or Data Privacy and Protection - Any technology or data used by the Customer that requires access rights will need to be documented in the Contract as part of Intellectual Property or Data Privacy and Protection. Address each aspect by both project role and use case. Note in the Contract the "terms of use" for each and how the use will be documented and tracked.
Project processes - define what and how they will be used, who gets access to systems, how staff are trained in the way of working. Waterfall or agile, phased implementation, or big-bang rollout, centralized or decentralized teams.
Service Level Agreements and KPIs - The supplier or the Customer may request Service Level Agreements and KPIs. Address the impact of 3rd parties to deliver SLAs or KPI's and the impact of failure to deliver. Be clear and reasonable, think through the likely scenarios that can occur, and make sure they are addressed in the Project and Contract.
SLA and KPI Standards should be documented and tracked regularly.
“One standard is worth a thousand committee meetings”
4. Define the When
When are key decisions, deliverables and tasks due? How are deadlines managed, what is the impact and outcome for missed dates?
In projects, timing is everything. So document when key tasks are performed :
by date (May 24, 2022),
passage of time (45 days after start of Project),
milestone (delivery of prototype).
or some other trigger - be clear about the trigger and action required
Be clear about timing. How long it takes to get materials and people. How long it will take to decide, resolve an issue, and the impact of delays. The impact can be in agreed slippage or penalties. Documenting these points in the Contract can help the project quote with delays out of the control of the Project. This way, the Project is not required to make up lost time. Or the Project can be compensated to allow for additional resources, or other options, to address lost time.
Dates and deadlines from project tasks to oversight need to be managed as part of the ongoing work of the project manager and their team.
5. Define the Start and Close of the Project
How to Start and End each project phase and/or contract well? What do consider with the beginning and end in mind?
Communication to Stakeholders, Team members, and Users - At the start of the Project, the communication processes are started. This needs to be agreed upon in writing since communication is such an important part of a project. If this is addressed after the fact, you may find the Project struggles to overcome communication issues since they were not designed and agreed upon from the start.
The Contract should discuss communication planning, execution, and strategy. This ensures the Project knows why, what, how, and when to communicate to various stakeholders. From the kick-off to the close-out - communication keeps the Project on track. So make it part of the contracting scope.
Implementation and Handover - Be clear about how the Project will end. What are the requirements to complete the work? How will the ongoing support of the final work product be handed over to operations?
Even a project with a long lead time needs to document what "done" looks like. If this is not knowable, then document that and confine the scope to a phase before this work is done. If this approach is used, it will mean that a new contract and plan will be needed for this phase of work. The more that can be documented, at a high level, the better.
6. Review Contract Terms and Conditions
How to understand the legal parts of the contract? How to look for inconsistencies and conflicts?
Legal Terms and Conditions are part of every Contract but should focus on about 20% of the content. Always read the Contract in full to ensure that the Contract is free of inconsistencies or 'errors.'
Terms and Conditions (T&C’s) should not:
counter project content
expand the scope beyond project content
apply new rules such as project governance
Terms and Conditions (T&C’s) should:
clarify meaning of key words
define scope of concepts
document if/then condition rules
T&C's concepts - get to know them and understand how they are used. To help, I have summarized a few concepts. Work with your legal professional to review in detail and address concerns before signing.
Definitions define the key points of the Contract. Just like a dictionary, the definition ensures all parties understand the subject they are discussing in detail. This can avoid confusion later and can impact the meaning of the Contract.
Terms - the rules and the guidelines acceptable to both parties. Terms should be explicit. Don't Contract for issues not understood fully by both parties. If there are unknowns in your Project, make sure that they are not treated as sure outcomes.
While the contract terms and conditions help to 'ring-fence a project,' it should also allow the Project to be changed in a controlled way. So, the Contract should detail how the Project is managed, documented, approved, and executed should be included in the Contract, where helpful include a change control exhibit and decision tree to show the process.
Condition - are generally if, then statements. (As an example: If you are billed, then you have 30 days to pay.). Again, once in the Contract, they become a rule, often subject to penalties if not done. (If you don't pay in 30 days, then a 5% interest penalty will be due for each month late).
Conditions often address points we hope never to have. Namely, when something goes wrong. When something goes wrong in the project staffing, process, product, or technology, relationships suffer—document how issues are tracked, managed, resolved, and, if needed, escalated.
No one likes to discuss these points upfront, but unfortunately, if you don't address them upfront, then it is too late to step back and formulate the rules of engagement in the heat of the moment.
7. Schedule and Exhibits to the Contract
It is helpful for the Contract to document 20% legal requirements and 80% project content as a reminder. However, to keep the document readable and make change control easier, it is helpful to use Schedules and Exhibits to document the project details. Most of these documents are part of the Project Workbook process, which the Project manager needs to create, manage and track. The only difference is that the Exhibits are contractually binding, so they should be higher-level than the details used on a day-to-day basis. How high-level? Enough to be contractually binding and indicate the Project's key criteria, requirements, resources, and outcomes.
High-Level Project Workbook
Use your Project Workbook to get started drafting the key documents for your Exhibit, since these will continue to be used through the project, it creates consistency in structure over the life of the project.
Don’t have a Project Workbook - get a free downloadable version and see an example version of a completed document here
Fit for Purpose and Standard Contract Schedules
Either Party made have required standards for Data Privacy and IP. Technology specifications and SLAs may need to be created or fit for the project needs.
Finally, a word on the importance of relationship.
A Contract is a tool to assist in clear and open communications between parties. Contracts set expectations and document outcomes, rewards, and penalties.
However, Contracts do not manage projects or relationships. This is the Project Management and Stakeholder's job. Good project teams are not based on Contracts. They are based on integrity, openness, trust, performance, and good communication. When something goes wrong or a misunderstanding occurs - address the issue as early as possible and as openly as possible to look for a mutually beneficial solution. Don't make your first reaction to address the legal route. Leadership, not "Legal-ship" will get the job done.
Communication is the 'gas pedal' to the Project - it keeps things moving forward. The Contract is like the 'break' sometimes. You need to step back and stop and make sure what is agreed to is being followed and is the right thing for the Project. Ways to do this while keeping the Project in focus are:
Define KPI's to track aspects of the Contract such as Budget and Supplier Payment
Add key clause points to the project steering meetings as a standard health check
Plan a contract view meeting on a regularly planned schedule (3, 6, or 12 months) to review the schedules and discuss amendments or issues to address
Contracts are a powerful tool to project success. Used correctly, they help start, run and end your Project to the satisfaction of all parties. This is why understanding how to use Project Contracts is an important skill for every Project Manager.
Find out more about contracts here:
The Special Challenge of Fixed Price, George Lowden and John Thornton, PMI
The Process of Managing Projects, Marcia Jedd, PMI
Long-term contracts and how to fix them, Oliver Hart, HBR
What did you think? Did I cover the topic completely? Do you have a story or advice to share? Please add a comment below or send me a note via the Contact link below.
I look forward to hearing from you!
