Finding a reliable development partner is hard. There are several factors to weigh, including time zone, cost, and technical ability. Some of these factors are filtered out through basic online research. But eventually, you will have to start talking to teams to see whether or not they are the right fit.

The process of getting from the introduction to a clear scope of work is the best place to learn more about a potential development partner. Yes, a good work agreement should provide clarity and a sense of security by clearly outlining the budget, the timeline, the roles and responsibilities, and the end goal (among other things). But it’s about more than just writing a detailed plan. The mindset of how to approach this process, and the indirect issues it should address, are just as important as the literal document it should produce.

This is what we strive for at Pristine Tech with our clients. It’s how we establish working relationships that lead to repeat business, and how we deliver technology that achieves all of our clients’ objectives.

In this first of three posts, we’ll lay out what you should expect from a reliable software development partner while setting up a work agreement.

Do they have a process?

This is something you learn early in any worthwhile sales training, you need a sales process. A process shows you have a plan for bringing clients on, it shows that it’s more than just “whatever you want, we’ll do it”, and it makes sure nothing gets missed. Your job as the client is to make sure that your project is clearly understood. It’s the responsibility of the development partner to guide you through building a connection with the team and making sure all the details and context are clear. There are several reasons for this, from not being able to create a useful estimate without that connection to confirming that the development team can do what you are asking, but it also establishes trust. It’s not theatrics, it's necessary. If you meet a vendor that seems to require you to determine every step of the discovery and planning, that may be a problem.

Shared understanding of done

More than just the technical requirements, what are the business needs this project addresses? It's clichéd because it's true and important. Every good project has a series of meetings to clearly lay out what the project is supposed to accomplish and who’s responsible for what. This should be documented, but it's not about getting a document that’s binding to restrict what you, the client, can ask for. It’s about establishing where you want to go and why so the development team can be sure that their code is done with that in mind.

For example, when Pristine Tech writes out feature requests, the literal description may be “the button goes here, and when you click it, X happens” but it is backed by a noted understanding of why, ie “this process is supposed to enable users to login and engage with other users." When you’re done with laying out what the final product needs to have, you should have a list of macro and micro goals, a timeline of when those are going to be built, and what people should be able to do at different stages. Then you can start breaking those out into tasks.

Genuine belief that you have each other’s interests in mind

Throughout the process of creating your project plan, you're learning what it is going to be like to work with that partner. If either of you approaches the process like a negotiation, that can put you into a mental state where you are assuming the other party is only interested in their own advancement. This can create a zero-sum dynamic where all you can do is try to lose less.

What you should expect instead is a collaborative process that demonstrates your partner adds value. Simply put, it's ok to expect the vendor to be genuinely invested in your success, and to be upfront about that. You may get pushback, and there is probably a reason for that.

Companies set policies and processes to protect themselves from harms they've observed or experienced. This can lead to controls that become restrictive. In the above example, when you ask for a collaborative partner, they may say they don't do that. What they don't tell you is, with a previous client, they tried to be collaborative, and the client ended up burning them by pinning failures of the product on the vendor. What that means now is, they only take projects where the client can come up with clear and specific directions for what they want.

There is nothing wrong with being clear about what you need and what you will tolerate. However, if a vendor isn't willing to adjust to what you need, you don't need to concede the point. They may have all the technical skills you are looking for, but if they won't provide the working relationship you expect, you should not work with them.

Mind and Matter

Finding a reliable partner is hard enough as it is, so it can feel excessive to bring this kind of rigor to the planning process. However, any good development partner will be more than just a bunch of code monkeys. They’ll bring a technical perspective that improves the process, and they’ll be genuinely engaged in seeing your goals achieved. If you can find a partner that has a thorough process, cares about establishing a shared understanding of done, and shows they are invested in seeing your project succeed, that’s a great sign that they can get you where you need to go.

In the next post, we discuss key aspects of managing the relationship throughout the project. Some of them also come up during the opening stages, but they will require practice during the project.

If you want to have a discussion about how we might apply this process to a project or initiative you are considering, we would love to chat.