How should my company deal with contractors that ignore our technical guidance?

Question

I'm a senior software engineer that works in a small group (4 other colleagues and one immediate manager to us). For an R&D project, we work with a contractor to develop some software tools and do some research and development for a software that is going to be incorporated into our future product.

The area of this specific project is my immediate expertise; although my manager is pretty familiar with the topic, he is not necessarily an expert in this area. I'm the main point of contact between the contractors and the product owner and my manager.

The result of each sprint is presented in biweekly meetings to our group (me + my 3 colleagues + my manager, we are all senior software engineers).

There is a crucial tool that needs to be developed in this project and there is an issue with the current implementation by our contractor. I did some tests and I'm pretty sure that I know what the problem is and how to resolve it. In order to show the feasibility of my solution and demonstrate that my idea could indeed get rid of the current issue, I created a Jupyter notebook and send it to our contractor last week to possibly use it and hopefully they could build on top of it to get rid of the issue.

Today, in our sprint closure meeting, the contractor team acknowledged that they got my notebook and that indeed it solves the issue that we are facing in our current development. After that, when they jumped to presenting their results, they still showed results that were produced by their old implementation. I asked if they got the chance to incorporate my notebook into their current workflow, and they respond that: well, while my solution seems to work but they prefer to stick to their original implementation without giving clear explanation why.

I don't want to look like someone that is pretty picky, but my main concern as the main point of contact for this project is that we won't be able to reach the project's goal without resolving that issue and my manager also has the same opinion. I set up another meeting this week to discuss this issue further and possibly dive into more technical details to get to the bottom of this problem, but my main question is: how can I make sure that our contractors incorporate our guidance into their development without being rude or looking as someone that is too picky?

Answer 1

we won't be able to reach the project's goal without resolving that issue

This isn't picky at all. Delivering working software is the entire point - if developers are delivering software which doesn't work, they're doing it wrong.

my manager also has the same opinion

This is good - it means it shouldn't just be able to degenerate into a "Mithridates said, contractor said" discussion.

how can I make sure that our contractors incorporate the technical comments and our suggestions into their development without being rude or looking as someone that is too picky?

Just ask them how they intend to resolve the issues with the current implementation. There are three realistic possibilities how they respond:

• They continue to waffle without giving a clear explanation. In that case, you need to push them for a clear answer - while this is direct, it is not rude.
• They describe a path forward which is different from your solution but you think may be feasible. Here, you probably need to give them a small amount of leeway to show their solution can work; I would suggest timeboxing it and agreeing to move to your solution if they cannot get their solution to work.
• They agree to implement your solution. All is good.

In the worst case scenario, you may decide that the contractor is not the right person for the job. In that case, you will have to start the discussion with your manager about how you replace them with someone more appropriate.

Answer 2

There is a key point that needs to be addressed regarding your technical guidance. That is:

Does the software actually work and do what you asked them to do, in terms of the actual response to user inputs?

If the answer is "no", then give them actual reports of bugs - what the software does and what you expected it to do in different circumstances. This is very different from "technical guidelines". You should expect that these bugs will be fixed.

If the answer is yes, it does work, and your technical guidance is you saying "we would prefer if internally the code had worked this way" then you can't really make them change things. You asked for code that did something, and they have delivered code that did that. Of course it's different if you told them in advance (and preferably in writing) that you wanted something done a certain way - then you can reasonably ask them to make changes so it works the way you told them to. If you didn't do that, and you wanted things done a certain way, then there's a lesson there that you should give your requirements in advance.

Answer 3

Do you have a DOD (Definition of Done)? Does it Include UAT?

When dealing with third party contractors I find having an Explicit Written out Definition of Done to be very helpful. The Story isn't Done until it meets the pre-agreed Definition of Done.

Does your Definition of Done Include User Acceptance Testing? If it does then create a Bug that expresses the Issue and leave the story\feature request open till it gets fixed.

If you Don't have a DOD or it doesn't include UAT then get one written up and get everyone's agreement. Then as you move forward you'll have controls to enforce what you need and ensure the project stays on track.

Answer 4

how can I make sure that our contractors incorporate our guidance into their development without being rude or looking as someone that is too picky?

I would give the contractor time to implement your solution. They needed results to present and perhaps that was all they could do until they get their head around your solution. Nowhere in your question does it say using your solution was mandatory.

If it's not implemented at the next meeting would be the correct time to push, make sure you have your manager on your side. Ideally your manager just makes it happen.

Answer 5

It rather depends on the contract you employer has with the contractor.

The contract may set out what they have to deliver and in what timescale. They are working on the project in their own way.

Then an employee of their customer tells them that they are doing it wrong, and tells them how to do their job. Their response is to listen politely, then ignore it and carry on as before.

Realistically, your job may be to ensure that what they deliver meets the stated requirements, and nothing else.

Answer 6

I'd ask you to consider two things.

First, good software must:

1. Do the right thing
2. ...for the right reasons...
3. ...in the most obvious way possible.

If software fails to satisfy even one of those three criteria, it is a complete failure, period.

People are wrong when they say "if the software produces the right experience, it's good enough." That is 100% false. Why? Because unless this is one-off software that you're going to throw away later, the source code needs to be high-quality so that long-term ownership is not a nightmare: it has to be easy to understand, modify, and improve. So if the source code is organized around ill-fitting concepts, or if it's filled with problematic anti-patterns, that means you're buying a piece of garbage.

It's a mistake to get hung up on whose implementation gets used. But:

• if one implementation is clearer than the other, it is better;
• if one implementation adheres to more of your organization's best-practices than the other, it is better;
• if one implementation is organized around the same first-class business concepts that are used by the rest of your organization, and the other is not, it is better; and so on.

Second, contractors are supposed to build software that satisfies all the requirements. Setting aside all other arguments about what makes software "good enough," you still get to hold the contractor to the business requirements: unless they are all satisfied, the contractor is not holding up their end of the bargain. You state:

there is an issue with the current implementation

and:

still they showed [buggy] results that were produced by their old implementation

So, it's quite clear that your contractor isn't even satisfying the first element of the aforementioned triad: their software does not do the right thing.

In light of that fact, their reasons are irrelevant: there is no rationale that can justify delivering software that fails to fulfill its purpose.

---

Perhaps the contractor has a different solution than yours in mind; fine: you are entitled to have them brief you on their plan in detail before they spend your money and time implementing it. Do not take "no" for an answer!

But you need to go to that meeting with an open mind: perhaps their solution is better than the one you're in love with, or is no less good. Do not lose sight of what's important: does the software do the right thing, for the right reasons, in the most obvious way possible? If the answer is yes, everyone must be satisfied; if the answer is no, more work remains. Nobody's ego has a role to play in this.

Answer 7

Most other answers have focussed on "the software needs to work" for why your fix should happen. I'm going to give a dissenting view here.

All of the software needs to work, all of the time

Your contractors are responsible for the whole of the software, not just the one missing/incorrect feature you've found.

It's entirely possible that your fix works for the specific issue you're dealing with, but has knock-on effects elsewhere. Maybe it breaks other functionality; or maybe it's functionally OK but it has performance issues which mean it won't scale up when you have a million users or a million points of data; or maybe it's only a sunny-day solution and doesn't consider error/exception-handling conditions; or maybe it uses a library which legally you can't include in a released version.

The important thing which you've given them is clear evidence of what the problem actually is. How they get a production-ready solution to that problem is their job. It's quite literally what you're paying them money to do, after all. You just need to set the expected deliverables and the deadlines.

You need to decide if this is a sprint or not

If this is a sprint, then what they're doing should have been established at the start of the sprint. If you've come along with something new, then it goes in the next sprint.

If you're going to stop the sprint and have them do something else instead, that's doable - but it needs more discussion than just sending a proposed fix. And if you wanted your fix to be added to the sprint (which is generally not how sprints work), that's also doable - but again you need a lot more discussion. You need to get clear buy-in from your manager, their manager, and their engineers. Normally that involves a meeting with everyone talking through it. There also needs to be an expectation that pulling someone off something else mid-sprint is going to involve some context-switching for them, which will be slightly less effective.

Basically the level of discussion needed is way beyond just "sending a notebook".

And you need to be a senior engineer

I'm concerned about the phrase

without giving clear explanation why.

If this is a thousand-foot-overview meeting for management, I wouldn't expect to discuss technical issues. But if this is a technical meeting between engineers - and a sprint closure meeting certainly is that! - then I certainly would. A discussion doesn't mean that they should just infodump on you. It's a conversation. If you have questions, you need to ask the damn questions!

As your manager, I would consider it unacceptable for one of my senior engineers to sit through a technical discussion about what's been delivered and only afterwards say "I didn't think that was right, but I didn't like to say anything". If you're a senior engineer, your job is to be on top of the technical details and know enough of what your more junior engineers (or contractors) are doing. If you don't ask, who else is going to?

I'm also concerned about you not appearing to respect the sprint planning process. You can't just chuck something across mid-sprint and expect it to happen.

Seniority as an engineer isn't just about how good you are as an engineer, it's about how well you can use your experience to enable your team. An unpleasant truth is that the more senior you get, the less time you spend doing your own work and the more time you spend digging other people out of holes. It looks like you've got the technical side sorted, but you can still use some practise on the team-leading side of things.

It's all a learning process

The positive elements to take away from this are a strategy for the next time. Firstly you need to get proper buy-in for changes you put forward. And secondly you need to not be afraid to be Captain Awkward if it looks like someone is trying to weasel out of giving a straight answer.