This is the second of three posts about establishing a valuable work agreement, and what we believe it requires to provide the clarity and security you need to maximize your chances of success.

If you followed the guidelines of the previous post, you should be all set for a comfortable project launch. In this post, we’ll discuss what arises in terms of managing the project agreement during the execution.

What could change, and how will you handle it

Every project, but particularly for startups, is going to have surprises that change the scope of work. This is a balancing act. You can’t allow every change, because that’s scope creep, and will completely blow up your resources and overwhelm the team. However, you also have to allow for some changes, because otherwise, you run the risk of killing the project’s ability to react to new information or changing conditions.

Agreement Setting

There are ways to build this into the agreements you create, but it’s tricky, and there is no perfect rule that resolves the issue. A common tool is to set hard lines on what qualifies as a change request, eg anything that takes more than two hours of work is a change request and will be billed extra. This helps but still requires trust and clear communication.

Let's say you're planning a project, and you and the vendor agree that a change request is anything over 5 hours of work. Two weeks later you say you want an adjustment to the ticket submission form, and the vendor says it's going to take 10 hours. If you don't believe they are on your team and genuinely invested in your success, you may fight that estimate, and having that number clearly set from the start won't prevent the fight or the negative feelings that result.

Changes are a process

It needs to be understood that, whatever guidelines you set, making changes is going to be a process you execute collaboratively. Because it can’t be rigidly defined before it happens, the first time you need to make changes, special care must be taken to set a standard for future change requests.

There are a couple of ideas that should make this easier to do. First, the project is all about achieving your, the client’s, business goals. If a change request is made, either the business goals have changed, or the thinking around how best to achieve them has changed, maybe both. This needs to be clearly stated and understood by both parties. The client should have a reason for making the change that explains why they want to make it. The vendor needs to understand why the client made the request so that, as they make the adjustment, they can advise on the implications of the change or how best to achieve the new goal.

Second, any impacts of the change need to be clearly understood and accepted before it’s made. If the consequences are ignored or minimized, you’re much more likely to have an unpleasant surprise toward the end of the project. It’s very easy to skip this step with excuses like “We don’t have time for that conversation” or “I’m sure they understand what this does to the budget”. Don’t make those excuses. You need to be clear about how the change alters resource requirements and the deliverable. In whatever way necessary, we at Pristine Tech are direct about what the impact of changes will be. Once we all know we are clear about the impact and still want to make the change, we move forward.

Work Agreements are Conversations

It is tempting, when designing and launching a project, to see work agreements as a set of boundaries within which the project happens. As long as you stay in the lines, the project is fine. But projects are living complicated processes, where everyone is trying to do their best to fulfill what seemed like the best plan at the time of launch. A good development partner can adjust where necessary, work with the client to minimize any potential damage, and still navigate toward the best possible business results.

Some of this comes through how you write and design the document itself. But a great deal of work is still required to collaboratively execute that plan as best as possible. If you go into a new project clear that the work agreement is just the best way to start an ongoing conversation, you and your partner are much better prepared to achieve your goals.

If you’d like to discuss what a potential agreement could look like for the project you are trying to get done, we would love to discuss your objectives.