In this article, you will learn about creating a software consulting agreement to establish clear expectations, minimize misunderstandings, and build lasting business relationships.
Table of Contents:
- Establishing a Foundation: Crafting a Consulting Agreement
- The Importance of a Comprehensive Service Agreement
- Key Elements to Include in the Agreement
- Outlining Specific Deliverables for Success
- Identifying and Mitigating Potential Risks
- Establishing Clear and Concise Fees and Billing Terms
- Building Trust: Effective Software Consulting Agreements
Establishing a Foundation: Crafting a Consulting Agreement
Scenario 1: You’re a COO looking to complete a project in a mission-critical, but costly, business line. You engage a software consultancy for their experience and expertise (even though you're still unsure if consulting firms are even worth your money 🙃).
Scenario 2: You’re a new-to-market app developer. You’ve done it for years as an employee, and you’re venturing out on your own. A startup wants to hire you to make their app, Hughub, a Grubhub-clone for Emotional Support.
What is Step 1 in both Scenarios? The Service Agreement.
For the rest of this post, I’m going to use the words “Service Agreement” and “Contract” interchangeably.
The Importance of a Comprehensive Service Agreement
Why is the Service Agreement important? There are obviously many reasons, but I will list a few here that I believe are the most important.
Build Trust and Security in Professional Services Agreements
When you enter into a contract for professional services, you’re agreeing to spend a lot of money. You need assurances. When you’re on the other side, and you’re the service provider, you’re agreeing to give up a lot of your time and know-how. You need assurances.
Contracts are there as an essential part of building trust between parties in business relationships. While trust is important, contracts provide a framework that helps to establish clear expectations and minimize misunderstandings. By setting out the terms of the agreement in writing, consulting agreement contracts provide a reference point for resolving disputes and building a sense of security and predictability in the relationship.
For those of you that are familiar with win-loss analysis programs and used to extracting data that really highlights areas your team has missed over time, I'm sure that you can appreciate these types of agreements that help keep everything "buttoned-up".
Preventing Misunderstandings with Contracts
Creating a software consulting agreement can help to build strong and lasting business relationships based on mutual understanding. They provide a roadmap for the relationship, ensuring that both parties understand the terms of the agreement and can work towards achieving their goals without fear of ambiguity or conflict. By establishing a set of rules and expectations that are agreed upon by both parties, contracts provide a sense of security and predictability that can help to build trust and prevent misunderstandings. In the end, contracts are an effective tool for building strong and lasting business relationships based on mutual trust and understanding.
To save everyone time and headaches, Anthroware has found that the Contract being a separate document from the Scope of Work tends to work out a little better. It’s all a pain to deal with, but separating those concerns makes things easier down the road.
Key Elements to Include in the Consulting Agreement
What goes in the Service Agreement?
Note: Anthroware is not a legal firm and cannot give specific legal advice. For what your contracts should say, please see a lawyer. A real one.
At a minimum, the contract should state the following:
- Provider is going to deliver services to the customer
- Customer is going to pay Provider
- Who determines the means and methods of service delivery?
- Standard Language about Works Made for Hire (this is a specific thing your lawyer will know about)
- Ownership of IP created during the engagement
- Nondisclosure
- Subject-matter relevant content (Anthroware has clauses about Hosting, Backups, and Response Time)
- Limited Liability
- Guarantees and Warranties
- How Changes in Scope will be managed
- How Breaches will be managed
- Applicable Law and other standard legal things
Again, see a lawyer about drafting your Service Agreement.
Defining the Scope of Work: Clarity Matters
The Scope of Work (SOW) is where the magic happens and you begin to foster trust and start creating customer intimacy. You should expect a lot out of a SOW. The purpose of the SOW is to outline what’s going to be done and on what timeline, and any specific fee terms. It should be understood by all, and have as many words as it needs to have to ensure that all parties are agreeing to the same thing. It’s very easy for a client and a provider to understand very different things about the meaning of things. This is why you're learning about creating a software consulting agreement.
Executive Summary
When Anthroware writes a SOW, we start with restating, in executive summary form, the problem that we’ll be working to solve. This is typically a page that defines the customer’s business. It then states the desired outcomes at a strategic level, not in “deliverables” form; we are showing that we understand the outcome that the customer needs from the endeavor and will thus support their customer retention strategy. “…so that Company A can reduce its HR budget related to 3rd party software fees.” is a good example of a desired outcome. These are outcomes that can be tested and proven later. This is important for trust building, and team alignment.
Approach
Anthroware always writes a narrative on the high-level approach that we’ll take on how we plan to accomplish the work. This talks a little about work cadence but mainly describes the exercises that the client will experience during the engagement. The approach should outline a high-level set of phases the engagement will go through.
For example, do our software consultants need to code? Or can we just use consultants and developers together? Trying to understand as many details as possible ahead of an engagement is usually very helpful.
Deliverables
Deliverables are the specific units of work that need to be achieved to call the work “done”. For example: For our sample startup, Hughub, the Deliverables should outline the app and the treatment of whatever is needed to make that app a reality.
Outlining Specific Deliverables for Success
Below are some examples of deliverables that could be part of a product research and development engagement.
Deliverables:
1. Mobile App Development (Both iOS and Android)
- 3 Step Onboarding flow
- User Account Creation & Authentication
- Subscription Billing in App Stores
- Curated Home view – This will be curated based on the users’ specific mental health risks and needs, and then subsequently sorted by the types of resources they tap.
- Order Flow - This will contain "Order Step 1 described", "Order Step 2 described", "Order Step 3 described", and "Order Confirmation email delivered via [Email delivery provider]"
- [Other Feature Description]
2. API Development
- User Account information
- User Logging
- Order Management
- Etc.
3. Web Administration and Client Onboarding/Management
- Feature 1
- Feature 2
- Feature 3
- Feature 4
4. Infrastructure setup consulting
5. QA & Testing
6. Training, Documentation, and Handoff from consultants to your team
Staying honest throughout the agreement
The deliverables should be specific, demonstrable, and testable. It’s so important to create this list. It keeps everyone honest regardless of how the market or environment might change throughout the engagement which could warrant new work or ideas to the product or services (sometimes this type of information is gathered later through b2b competitive intel). This is also why we use an out-of-scope section. We want you to know exactly what you're getting from your software consultant and the software we're building for you.
Out of Scope
We always include an Out-of-Scope section. With most clients, there are areas they do not want us to go to. Whether they have their own design team, and only want us on the tech side, or vice versa, it’s equally important to know what a team is not going to do. For example, many of our partners originally contacted us just because they loved our human-centered design examples and wanted us to do purely design work for them. Further down the road, we would make a new contract if it was for something else like development or research.
Identifying and Mitigating Potential Risks
Anthroware always includes a Risks section in its projects to identify potential risks. One example of this is working with a client's internal IT team without mobile deployment experience, which required additional training and processes to mitigate the risk. It's always better to stay on top of risks rather than, for example, the moment when Anthroware optimizes their QA process, to point them out.
Risks
I'll say it again, Anthroware always includes a Risks section. This is very important when creating a software consulting agreement. An example: Years ago, Anthroware worked on a large-scale app in the Home Healthcare space, and one of the major risks in the project was that we were working with the client’s internal IT team who didn’t have experience in managing mobile deployments and the DevOps roles they would need. We needed to spend time with them training and creating processes, and even helping interview new team members for them – it was just something they had never done. Calling that out early was important for team alignment and trust building.
Establishing Clear and Concise Fees and Billing Terms
To establish trust and avoid misunderstandings, fees and billing terms should be clear and adhered to without fail. While it may feel uncomfortable for beginners to write down their fee structure, it's a necessary step in the professional world where clients expect clear and concise billing terms.
Fees and Billing
Nobody likes this part. The Fees and billing should be clear, concise, and unarguable. $X is due on Y date. It should state what happens if payment is not made on time, and it should be adhered to, without fail.
If you’re in Scenario 2, you’re just starting out and you’re getting your ducks in a row, writing down your fee structure can feel dirty when you create your first software consulting agreement. Remember this: The COO in Scenario 1... they’ve already done this. It’s not personal. They know that engaging with a Software Consultancy costs money. It is no surprise. Indeed, they’d be surprised if this section was not clear and concise.
Building Trust: Effective Software Consulting Agreements
What’s the main takeaway here? Why did you spend time reading this?
In your business, questions will arise. All the time. But the one area you don’t want any questions about is in your contracts. Over in the Reddit Small Business sub, the number of people who ask a question that could have been answered by a well-written Service Agreement is shocking.
Service Agreements give everybody involved the confidence to know that they have something to fall back to in the event of a question or conflict. That’s what they’re for. So never work without a software contract. If you’re buying services, don’t buy without a good Service Agreement. If you’re selling services, don’t work without a good Service Agreement. Mutual adherence to creating a software consulting agreement is a sign of good discipline and a conscientious professional services provider.
