Software consulting projects are deceptively hard. Software systems are dynamic with a lot of moving parts, and there are several ways users interact with them. When we start with a blank page, it is hard to capture all these dynamic sub-systems and interactions. Users may have preferences based on the software they have already used, which may not be stated explicitly. Engineers often don’t understand all the aspects of users' requirements and make their own assumptions of the functionality. And everything that is agreed, is subject to change. Once software starts getting built, priority may change based on the initial usage. To sum it up, there are many cups and many lips in software consulting and development, leading to too many slips, and Murphy is always lurking.

When a software project is outsourced to a vendor, there is also a mismatch of goals, as both parties seek to maximize their own profit from the deal. While most of these issues are known, they are heavily underestimated. It is extremely rare to have software projects go smoothly where both the customer and the vendor are happy. No amount of planning can help mitigate this. In fact, in many cases, planning may be detrimental to the overall execution of the project, giving rise to different methodologies like “agile”.

Having worked with software consulting on and off for several years now, there are certain things I have realized that make for good customer-vendor relationships. Since such relationships are full of minefields, all we can do is avoid them. And this is done with good communication and coordination, the bedrock of such relationships. Each party must understand the other party very well and the relationship should feel more like a partnership rather than a client-vendor one. The project will be a success only if both parties win.

There are certain things one can do to mitigate these risks:

1. Go live fast and be “agile”

Due to the above uncertainties, an agile method is much better than a planning-based model. While there are several flavors of agile, there are some principles that are important.

1. Clear goals: The project should have well-defined and measurable goals. The progress should be based on the goals and not based on what technology or solution is used. For example:
   1. Number of students registered
   2. % of tickets captured
2. Go live as fast as possible: Software development should be iterative. The first version should be live as quickly as possible and then there should be continuous improvements.
3. Co-develop with the user: Once the system is live, further development should happen based on user feedback and the broad roadmap of the software project.
4. Fast release and iterations: Releases should happen on a weekly/bi-weekly basis so that new features get tested and improved rapidly.
5. Regular feedback cadence: There should be a regular feedback call (each week?) where the project owner, users, and the engineering team discuss tasks for next week.

2. Start with a proof of concept (PoC)

Sometimes when parties haven't worked with each other, there can be a small trial that both parties can use to test each other. This should be in the form of a paid “proof of concept” project that should ideally run for 2-4 weeks. The project should have a fixed scope and a fixed number of engineers (ideally one) working on it. If this works, the project can be extended.

The PoC should be designed in a way that both parties work together on the project. There should be a regular cadence of meetings to review the progress where the project owner and the engineer must be available.

The PoC should help the customer evaluate:

1. How well does the vendor understand the requirement?
2. Does the vendor deliver based on weekly commitments?
3. What is the quality of the engineering talent?
4. What is the quality of output?
5. What kind of taste does the vendor have for user experience (UX)? Does it match the customer’s taste?

For the vendor, it will help them understand the customer as well:

1. Does the customer have a good grip on what they want?
2. Is the customer able to communicate requirements?
3. Does the customer give quality feedback on the work done?
4. What is the customer’s taste for design?

And most importantly, it will set a benchmark for pricing for both parties.

3. Engage with a monthly retainer and billing

While the broad scope of work and goals should be defined, once an “agile” project has started, it will move in all kinds of directions. Some of these may be planned, and some may be opportunistic, so it is almost impossible to define a fixed end goal for a project. The minimum duration for any project should be 3-6 months. It is better to have fewer people working with longer timelines rather than get more people working on shorter ones. More people mean more management and overheads and generally lead to slower projects (Brooke’s Law).

How to manage budgets?

Since the software should be live as soon as possible, the customer should be able to see value at any point in time. And since there is usually no finishing line, the duration of the project can be based on the return on investment monthly or the budget for that project. If you are a customer you have to expect the project is already live as soon as possible and you can end “continuous improvement” anytime you want.

Typically a one-month notice to end the project will keep the vendor on their toes to deliver a “return on investment” for each round of improvements. This model works for the long-term interest of both parties.

Wrapping it up

Projects get executed the best when there is a high amount of trust between both the parties, and this can be achieved if both parties are focused on long-term goals and there is good communication at all points of time. The evaluation of the project should be goal based rather than based on any specific technical requirement. The pricing model should capture the complexities of software projects, and a monthly retainer works best. The goal should be to go live with something as soon as possible. As a vendor, you know you will continue to get business as long as you show continuous return on investment, and as a customer, you know you can cancel the project anytime.