To look at a vendor invoice or project report, and know that your spend is outpacing your expected return is an uneasy feeling. Being able to project how late and how far over budget the project will go compounds your anxiety. In these situations, it is easy to fall victim to sunk cost bias. Defined as our tendency to continue to invest in a losing proposition because of what it has already cost, this is potentially dangerous behavior. Regardless of the amount of time and money invested with a vendor to develop a product, if the performance to date has been poor, the path forward will likely continue to yield less than ideal results.
Luckily, being able to detect problems early is easier with digital products versus other industries. Progress in the form of functional software proportionate to the amount of money being spent should be observed from the very beginning of an engagement if agile practices are being used. If your spending is high, delivery progress is not as expected, promises are not being kept, or delays are common, some digging probably needs to occur. To help, following are some indicators that you’re in deep s!?$ with your tech vendor.
1. Are they transparent?
The level of transparency your vendor volunteers is quite telling. From unrestricted access to the team’s backlog tool to detailed line-item billing, there should be adequate and consistent transparency. If obfuscation is common practice, you will likely experience problems. Transparency drives accountability. We’ve worked with a number of clients that changed vendors for a variety of reasons. One recurring symptom we tend to hear is their prior vendor’s lack of transparency.
2. Too much talking?
A vendor that comes in with guns blazing and does not carefully listen to you explain your needs or does not request to talk with your end users should be a concern. You know the problem you are working to solve likely better than anyone. Jumping into a solution without understanding the challenges in the context of the user is a recipe for disaster. If you find yourself being talked at more than being listened to about product and user needs, it may be a foreshadowing of problems ahead. When it comes to what needs to be built, your vendor should be listening to you and your users.
3. Too much listening?
Be wary of overly accommodating vendors, however. Seemingly counter-intuitive, this can be indicative of a vendor that will say anything to win business and likely hide problems later. For effective development, process and discipline are necessary. If the vendor does not have the confidence to challenge you and your team to maintain this discipline, you may be adding external cost without increasing velocity.
While speaking with a senior executive at a client recently, he told me that we had, “Hurt some feelings” on the team. He followed by saying, “However, if some feelings need to be hurt to help the team improve themselves and the process, I’ll expect your team to do so.”
I’ll admit this sounds cruel. However, a vendor should not only accelerate development by providing incremental resources, it should also help your team work more effectively by teaching process, providing constructive criticism, and leading healthy collaboration.
Contrary to ’too much talking,’ when it comes to how the product should to be built, the vendor should be guiding and pushing the process.
4. Are they unwilling to change course?
Team retrospectives are critical to ensure a healthy exchange of dialogue around issues and successes. An open conversation around what has been working versus what has not should occur after each sprint (working team level), and quarterly, or after each release (stakeholder level). Are these conversations being requested by the vendor? Is the vendor acknowledging, and where applicable, adapting to your concerns and feedback? Specifically, if the vendor is dropping the ball, are they presenting a clear plan that holds its team accountable on how that team will recover? Within custom application development, it is not if something will go wrong, it is a matter of when. The true measure of a vendor, therefore, is how quickly they can identify, respond, and recover. We have found that by surfacing issues early and by addressing concerns immediately successful realignment occurs.
5. Are they fixated on the contract rather than the user?
Is the vendor helping you build the best product possible by encouraging user testing and subsequent iteration, or are they fixated on the original requirements and contract? Scope changes certainly have an impact on the project and discussions need to occur when these arise. However, if there is no flexibility to iterate, it can be indicative of a vendor that is more focused on getting paid than building you the right product. Stakeholders (the ones who help create the requirements) have inherent biases. We all do. If there are no plans built in to get the product in front of end users, questions should be raised.
Is it time for a change?
The decision to change vendors at any stage of the development process is undesirable. Even late in the vendor selection and contracting process this may feel less than ideal. However, running over budget, releasing late and ending up with a sub-par application is a far less desirable outcome. We have provided a checklist to help you evaluate if you should consider switching vendors. Some specifics to consider when the time comes to end a relationship with a vendor are also included.