Dealing with Difficult Software Vendors

Relationships with vendors don’t normally start as difficult. They devolve into difficult situations and are ultimately a result of the behaviours and needs of both parties in the relationship being unmet.

So how do you see the warning signs early? How can you deal with vendors once they have officially become difficult?

Let’s take a look at difficult vendors by looking at the kind of problem you’re going to be facing: the seven problems…

Problem #1: “Our job is done”
The most common issue that creates friction between the client and the vendor is the transition from the sales process into the implementation process. The sales process seemed promising, but the disconnect between the sales and delivery make it feel like you’re ‘starting from scratch’ with the implementation team after investing vast amounts of time in the presales process essentially training the wrong people.

How can you fix this?
There are two mitigations to this issue: instigate a change to the engagement dynamic or expect the dynamic and operate accordingly. Changing the dynamic may work for certain vendor relationships where you can call out the issue and ensure that you have teams that cross the boundaries of pre and post sales. The other option is to expect the anti-pattern and force the sales team through the negotiation process to assume the associated costs of ‘re-briefing’.

Problem #2: “Lots of smoke. No fire”
The sales team either oversold their ability to deliver or generally underestimated complexity, and now the implementation team are trying to figure out what they have been signed up for. Some ways in which you can see this issue manifesting is: Lots of talk, lots of people seemingly doing things, but no real traction or output. Usually, this is the case where the vendor has strong project management but lacking great engineers or what Google calls ‘Smart Creatives’ that can really crack what needs to be done and do it.

How can you fix this?
You need to call it out and get answers. There may be a serious case of denial coming from the vendor – especially if they have inherited a complex project rather than developed it themselves. The only solution is to force the team to break the key problems down into pieces and start solving them one at a time. The key to this is agreeing on some demonstrable results and a time frame to do it. Then tackle the next piece and the next until the vendor gains confidence and builds pace. The alternative is that the vendor is unable to deliver on the smaller pieces and at least you have found out sooner than later.

Problem #3: “Dug a hole too deep”
The alternate version of a vendor being out of their depth is the situation where an aspect of the solution being developed has a level of complexity beyond the skills of the engineering team. Even though work continues in earnest, progress stalls – this could be a critical feature or it could even be the system overall. Having frequent demonstrations of results (called ‘showcases’ if you are coming from the scrum agile process) where real stakeholders are involved is the best way to get visibility.

How can you fix this?
When a vendor is out of their depth, the best thing they can do is be honest. This does not always happen until way too late.

Problem #4: “Lord of the Flies”
Sometimes you see amazing work. The vendor is able to do astounding feats of engineering and make it seem easy. This is the sign of a creative, engineering-driven organisation. The problem comes when it is time to deal with the details. If you see fast turnaround with lots of quality control and testing issues, especially regression issues, you know you’re stuck on an island where the creative engineers are in charge. Lots of execution, but lacking discipline.

How can you fix this?
This problem is so easy to fix – it requires application of simple process and discipline. The real issue is that most vendors that suffer from this problem are not aware of the root cause. The structure of the team is imbalanced and they desperately need some detail-obsessed project managers. Creative engineers applying process and discipline is bound to fail. The key is having the right balance of creativity and discipline on the vendor side – and making sure this is balanced with a real ‘product owner’ on your side too.

Problem #5: “Black box syndrome”
I can’t remember where I first heard the golf swing analogy when it comes to software development – but I love it. It goes like this: as far as the customer is concerned, trying to scope a project all at the start and then hand over the project to an ‘implementation team’ is like the teeing off and hoping for a hole-in-one. The smallest fraction of an error when you hit the ball is magnified over distance. A process that provides transparency throughout the project where the vendor engages with you and demonstrates the product in detail at regular increments – like a well run agile scrum process – is like being able to adjust the trajectory of the ball mid-flight. The longer the fairway, the more adjustments you’re going to want to make.

Black-box syndrome is the opposite of this; a vendor that refuses to provide transparency, and does not want to provide anything but the finished product is usually a recipe for disaster. The problem with this approach is its inherent convenience: It is just such an attractive solution to be able to give the vendor all the details at one point in time and then just get a finished product. The reality is that this situation unknowingly puts enormous pressure on both you and the vendor to develop the scope to perfection. Realising that this is not possible, the place things will next come to a head is at completion.

How can you fix this?
Demand regular, structured interactions where you are seeing progress and providing feedback on next steps. Ultimately, this is the whole point of scrum/agile process and it’s what you’re asking for. See more solutions in Problem #6: ‘Just trying to help’.

Problem #6: “Just trying to help”
A variation of the Black Box Syndrome is the vendor that tries to help when working with a client that does not understand the importance of the transparency provided by the vendor – or does not have the capacity to interact at the level they need to. Novice client-side ‘product owners’ will quickly cede responsibility for definition, prioritisation and interim reviews of work to a zealous vendor eager to help. By seemingly ‘picking up the slack’ the vendor is actually creating the foundations a dysfunctional client-vendor relationship – one that is destined for failure. The responsibility for defining the fine details of the product, prioritising features and accepting the work being done absolutely has to be done by the client.

How can you fix this?
Start with some simple disciplines and include them in the routine of the vendor’s agile delivery process – these are:
1. Definition of ready
As the client-side ‘Product Owner’ sorts the backlog by priority, the vendor’s Project Manager or Analyst will work with the Product Owner and the Development team to build up the level of detail in the top-most stories so that they are ‘sprint-ready’; that is – they should have enough detail in them including clearly defined acceptance criteria such that the Product Owner agrees on the criteria represent the story accurately and the Developer or Design agrees that it is estimable and actionable. Work can never start on anything that is not passing the ‘definition of ready’

2. Definition of done
While the stories in the backlog should have their acceptance criteria defined, there are some acceptance criteria which should be articulated at the project level and should be applied to every story. This model allows for cross-cutting concerns that affect the software to be articulated once and referred to throughout the sprint cycles.

Examples of universal criteria would be:

  • Specific security requirements that affect every piece of code on a platform
  • Design principles that should affect every user interface element
  • Form-field validation criteria for every place data is provisioned by users

The idea of universal DoD documents speak to the driving principle of agile – namely, minimise documentation and focus on working software! If we can reduce the size of stories by universally referring to the DoD throughout the project we have clarity for the team and a consistent piece of software.

3. Formal acceptance
Don’t just have the definitions, ensure that every iteration of work being done by the vendor is signed off before (ready to be started) and after (signifying what was done is right at this point)

Using this approach you will solve the gap for understanding how to manage the vendor, however it does not reduce the effort required in collaborating with the vendor to get the results. The harsh reality is that there is no easy alternative or shortcut for this.

Problem #7: “Everything is a nail”
In Abraham Maslow’s The Psychology of Science, the saying was coined “if all you have is a hammer, everything looks like a nail” which illustrates the concept known as the law of the instrument, which is a cognitive bias that involves an over-reliance on a familiar tool. Vendors that are specialists in using a specific technology can easily find themselves falling prey to this bias – seeing how they can solve your problem with their tool, platform or service.

How can you fix this?
Once you have engaged the vendor, you’re the nail – so best to determine if their hammer is the right tool for the job before you have engaged with them. Sometimes approaches to a solution may be interchangeable, unfortunately sometimes as the level of understanding of requirements increases, this is not the case. The only way to know this is to perform enough analysis prior to engagement. Having a vendor with more than a single platform or area of specialisation can help mitigate this risk.

Leave a Reply


Your email address will not be published. Required fields are marked *