Categories: supplier management
Are you working with suppliers on your project? Chances are you probably have – or if your current project doesn’t require external contractors/suppliers, then one in your future probably will. These days, it’s common to have suppliers partnering with you on a project because companies choose to outsource work to those who are specialists.
However, a lot of project failures begin an end with customer relationships breaking down between you and the supplier. I remember one (huge) project we were going to work on and we had a supplier in mind. They were lovely people as well as being specialists. We were at the point of signing their contract and then… the deal fell through. I can’t go into the specifics of why, but suffice to say that as a project team that gave us a big problem. Our preferred supplier was no longer available, and we needed a replacement fast.
In hindsight, that was a great project for learning about contracting.
Building collaborative contractual arrangements
When you set out to nail your suppliers to the ground, and get the most out of them for the least possible price, you are setting yourself up to fail. Not only is not ethical business practice, it puts your project at higher risk because you are creating a ‘them vs us’ or ‘winner vs loser’ situation. Be a nice client.
Taking a collaborative, partnership approach is something that will be common to many of you, including those on agile teams. I’ve worked in partnership with suppliers over several projects and many years. It’s always best for team harmony and productivity, and project success, for the supplier to be fully involved, supportive and partnering with us as part of the core project team.
Let’s say you want that for your project, but you still need the formal boundaries that come with having a third-party relationship with another company. Here are some contracting techniques that you could consider as the building blocks of your relationship.
1. Multi-tiered structure
Be more flexible. Document different elements of the project in different documents. You can have a master service agreement and then add on extra elements as the project progresses. Then you can amend the schedule of services to meet your current needs. Use a statement of work if you need more formal ways of defining scope elements etc.
Having a more flexible way to procure services makes it easier to make changes and gives you more options with how you work together.
2. Focus on value, not progress
The contracts I have been involved with have all hinged on having fixed milestones based on delivery or phase gates around when certain moments come to pass on the project. That’s OK, but you can also look at staggering contract payments based on the delivery of value instead of particular artefacts. That’s something I would look at for future contracts. If you are focused on value-driven deliverables, there is more incentive for you both to be agile and flexible to achieve the goals.
3. Price by increment
Another suggestion is to have flexible pricing based on smaller aspects of the project e.g. user stories, instead of one big payment for the whole thing. Fixed time and materials contracts are not something we use very often because they tend not to work out for either us or the supplier. If you know exactly what you are buying, and they know exactly what they are delivering, perhaps that will be OK. But for the kind of work we do, it’s more helpful to have a fixed price plus add ons for extra things. It gives us more control over how money is spent and lets us change our mind (with agreement from everyone) later in the project if necessary, without putting a financial burden on the supplier!
4. Cancellation options
Consider adding in cancellation optiosn that let you both escape the contract early. But build in enough notice for you both to make a graceful exit. One contract we gave notice on had a 3 month notice period. Given that it was a legacy system, in use for years, and with multiple integrations, it was difficult to extract ourselves in such a short period of time!
Another way to look at this, especially with agile work in mind, is that you should be free to exit a contract if you have got enough out of it. For example, let’s say you contract with a supplier to do a bunch of work, but you get to a point where you’ve achieved adequate business value from only half of the original scope. You don’t need to go any further, so you should be able to exit at that point. If the project contract has been written effectively, hopefully the supplier will not be at a loss either – you’ll want this to be a collaborative discussion. A cancellation fee could offset some of the inconvenience to the supplier, while still ‘getting back’ money for you.
5. Fund the team, not the deliverable
Another flexible way to build a solution that meets your needs in an agile team is to embed the supplier’s expert resources directly in the team. You basically buy in the skills you need, for the time you need them. They work alongside you, on whatever scope elements or user stories are at the top of the priority list. Then you are reserving the right to change scope or make flexible direction shifts, while still working with expert supplier resources.
This option works if you need what’s in people’s heads, or a spare pair of hands – but it’s less useful to you if your project is using what the supplier makes themselves.
There are other ways to look at collaborative contracting and the Agile Practice Guide has more information on alternative ways to have formal, but flexible, relationships with third parties.
Pin for later reading: