Client - Technical Vendor Relationships

Relationships can be hard work and when money, deadlines and complex technical requirements are involved they can be even more of a challenge.

Since the emergence of the digital era, commercial economies have seen considerable growth and we now live in an age where almost every workflow is assisted, or even dependent on, software.

It would be impractical for every organization to have an internal technical team developing sophisticated custom software. This has evolved a market where outsourcing complex technical work is a common approach for most industries. Outsourcing, by its very nature, relies on strong and productive relationships with external technical vendors to be successful.

As with every flourishing sector, the development market has become increasingly competitive and commoditized. This has resulted in every vendor positioning themselves and their solutions as the “best in class” for “boosting your business and meeting your digital needs”. There are numerous cases where these early promises have not been realized, with vendors being accused of not meeting quality, timelines or budgets and clients accused of being vague with their requirements or continuously changing them. Project deliverables and payments or often withheld as a result of deteriorating relationships.

So, why does achieving a successful client-vendor relationship appear to be so challenging?

Clients’ expectations of vendors, a lack of understanding of the market challenges and insufficient technical knowledge are often the underlying causes of incomplete project briefs, and it is these briefs coupled with the fact that vendors operate in a commoditized market, that cause the vendors to misinterpret the needs of the clients. This results in mismanaged expectations, budgets and timelines being exceeded and a breakdown of the relationship.

These are the limitations of both the parties involved.

Vendors are:

  • Too focused on starting development, and less on planning sufficiently, often skipping Non-Functional Requirements and going for the easiest solution to keep costs low
  • Develop according to their capabilities rather than what is in the best interest of the project
  • Under-estimating or not including research, consulting and testing time
  • No or insufficient risk margins added to estimates

Clients are:

  • Eager to get as much work done for as little budget as possible
  • A tendency to spend too much time worrying about minute details and losing focus of the actual business goals
  • Budgeting for the development cost only, forgetting or underestimating marketing, training, legal and many other related (and required) costs
  • Not margining for changes during the development process
  • Insufficient project scoping and briefing - often due to limited technical experience or weak project scoping capabilities. Changes are normal in custom development, the best you can hope for in a project scope is around 85% with a project manager experienced in digital solutions and sufficient technical support. The problem is that clients tend to assume they have covered close to 100% of the requirements and don't expect or plan for changes later on.

What can clients do to make the relationship thrive?

Clients need to understand that it is a commoditized market with vendors competing on price. Because of this, estimates are often based on the least costly implementation looking only at the functionality that has been specifically briefed. There is often an assumption that vendors will be consultative, but this is a luxury that cannot be afforded when competing on price. To level the playing field between the vendors and to ensure realistic estimates the client needs to improve their brief, their vendor evaluation and selection process, and their communication.

  • Ensure sufficiently detailed requirements are scoped in an industry standard format such as Agile user stories. All requirements need to be validated by actual users of the system and should have a clear ROI.
  • Besides functional requirements, also create non-functional requirements (NFRs). These will add context and will ensure the right architecture and experience is designed for the non-technical goals of the solution.
  • Make decisions on key technologies before finding a vendor. This will ensure that the technology is chosen based on the needs of the project and not based on the capabilities of a vendor. Many vendors will claim that their preferred technology is the best option - not with any malicious intent, but based on their experience with that particular technology and without sufficiently comparing it to other options that they may be less familiar with.
  • Always ask for a multi-year estimate that includes initial development as well as 3-4 years of operating and maintenance costs. Different solutions have different price points because some are easy to build but can be costly to maintain (Custom Wordpress projects) and others are costly to build but easy to maintain (Serverless Architecture).
  • Be transparent to the vendors on what they will be evaluated on - that it’s not only about price. Don’t assume, communicate your expectations for research, consulting and anything else and ask the right questions to understand how the vendor operates internally for quality, testing and security.
  • Ideally, share your approximate budget range for the project. There are many ways to implement and the budget will help filter out those that are the best quality within your available budget. Make sure to set aside budget for non-development activities where needed (training, marketing, legal, etc.).
  • Have regular contact with the vendor. Most vendors follow an Agile approach to projects which includes daily 15 minute meetings. Make sure someone from your project team with project management capabilities (ideally Agile) attends this meeting.
  • Changes will ALWAYS happen during custom development projects. Margin accordingly and carefully consider every change request for its value (ROI) and urgency. Projects often get delayed due to too much focus on details. It’s more important to get the project live, even if its only for a small group, so that changes are driven by actual user requests and not assumptions.
  • It is important to understand that no one can deliver a perfect solution on a first attempt. Reaching perfection is a journey of iterative improvements. Focus on what is going well, provide constructive criticism to improve the areas that are not going well.
  • Accept that testing an application is an absolute necessity and that sufficient time is planned for this. The vendor should always assign dedicated testers to your project to support the developers. Testing needs at least as much time as the development itself - much of this will happen in parallel with the development but make sure to plan for time after development for your own and user testing.

What can Vendors do to make the relationship thrive?

Vendors need to stop competing on price. Which, I know, can be difficult when you are fearing for your business’ future but the current market is unhealthy. Vendors can do more to educate clients on quality and they need to be more transparent.

  • Margin estimates and include research and consulting but be clear about why this is needed and the risks of not doing it.
  • Identify the actual needs and requirements of the client. Always write up a brief focusing on your understanding of the project from the client’s brief. For example, a functional write up based on the client’s user stories. Make sure the client provides non-functional requirements to give you context and non-functional goals to consider for the architecture design.
  • Recommend which features could be dropped to improve the quality of the remaining features within the available budget and be transparent in what can realistically be delivered within the available budget without degrading the quality.
  • Be very transparent in your quotes/estimates - remember that it is not only about winning a project but also about managing the expectations of your potential client. Walk the client through itemized estimates and explain the “why” for each item. Especially testing, never underestimate testing or accept a client’s demand for less testing time. Explain to them why it is essential, agree to do testing based on hourly tracking if they don’t want to commit to bulk testing hours up-front.
  • Insist on the client assigning someone to attend the daily stand-ups, provide a clear weekly update with hours worked, changes made and tasks that were not completed with the reason. Provide a clear overview of which tasks are expected to be completed on which date. Make sure the client understands that these are moving targets and the reason each time they move.
  • NEVER do any work that has not first been estimated and approved by the client unless you are willing to do it for free.
  • Avoid over-committing and optimistic estimates so that you can avoid under-delivering. This makes clients unsatisfied, which means that feedback will almost always be negative. Be clear if an estimate is a rough ballpark, or a detailed estimate based on deep research of the project requirements. Acquaint the client with the different options to develop the solution, together with an overview of pros/cons, price point and quality expectations for each option. This allows the client the space to make the decision with full transparency.

Bad relationships and failed projects are not pleasant for either party. After a bad experience, they both move on with a more cynical approach to the next project and more likely to start from a position of mistrust. There is always a better way of doing things to be more effective. We must understand that no system is perfect but if the shortcomings can be identified and addressed, and both parties can learn to work with each other in a different, more transparent way, things can certainly improve for clients and for vendors alike.