Everyone and their uncle is doing agile software development these days. It's very rare to see teams work with detailed upfront specifications. Even companies where analysts write prose, often leave plenty of leeway for devs to fit the solution into reality. The days of strict Use Cases and UML are long behind us.
This contemporary approach of small, continuous increments and feedback works wonders when building a product. But it runs into limitations when working with projects. The noble art of project management has all but been forgotten in agile software development.
And to be clear: that makes perfect sense. If there is no Iron Triangle of Scope-Resources-Time, there is no project to manage.
One of the scenarios where I often see this go wrong is when working with external vendors. When we pay outsiders to build a product or component for us, the need for project management becomes evident.
In the old days, this kind of collaboration would be a vendor project. A fixed-price project, to be specific. We would agree on detailed specifications and pay the vendor to implement the component for a fixed fee and deadline. A real Iron Triangle.
Fixed-price projects put the project risk with the vendor. If their estimates are wrong and they need to put in more hours, that comes out of their own pockets.
In the opposite approach, hourly billing, the client assumes the risk. If the estimates are off, the client will have to buy more hours.
Clients love fixed-price as it de-risks software development for them. Hourly rates are typically less expensive but more risky.
But these days, when we're all agile software developers, I see a sneaky third way that's very popular: Fixed Budget. The client and vendor agree on a general, high-level scope and budget. They'll have some written specifications and a few Figma designs. But instead of having a clear Iron Triangle, the vendor will try to fit all the work into the allowed budget — Agile style. It sounds a lot like Fixed Price, but it's not. The risk remains with the client. It’s a best-effort contract, not a commitment. And that means that, even though the vendor is probably using agile software development methodologies, the client needs to apply project management techniques to ensure they get what they paid for.
Here's how we do that.
Create a scope
Have the vendor list all the work. This doesn't need to be detailed nor exact. Every team uses some kind of ticketing system already, so just demand access to that. You should never directly add tickets to their Jira board, but you should be able to check their real-life progress.
Now that you have access to the project backlog, you have a crude scope. No need to estimate these tickets, just count them. If there are 120 tickets in the backlog, you can consider that 120 points. If the vendor still has some Epics to clarify, you can count 10 points for every Epic until it has been refined. Don't put too much effort into estimating the scope. It's a guideline, not a science.
Create a spreadsheet
You can't be a project manager without an Excel sheet, so get cracking. The sheet doesn't have to be super fancy to be useful. I like this format:
Every sprint, I ask the vendor for a budget update and feed that into the spreadsheet. I also count the total number of tickets on their backlog and the total number of tickets in the Done column.
While pretty low-maintenance, this spreadsheet shows that they have burned through 54% of the budget, but have already delivered 68% of the scope. This vendor is well ahead of schedule!
Help them succeed
In fixed-price projects, there's the time-honored tradition of squeezing the vendor. Since you paid a lot of money for the vendor to assume the risk, you might as well get the most out of it. There is a certain type of project manager who would negotiate to squeeze the most out of the collaboration with a vendor.
While a dubious tactic in fixed-price, it's counter-productive in a fixed-budget scenario. Squeezing the vendor always leads to low-quality software, and given that you assume the risk, the cash required for those bug fixes will come out of your pockets.
Instead, treat the vendor as one of your own teams and make it easy for them to succeed. Notice they are behind schedule? Offer to cut some of the scope. See them struggling with a challenging design? Allow them to simplify it.
In a fixed-budget agreement, you, not the vendor, are responsible for making it all work. So put them in the best position to succeed.
Trust, but verify
Hiring a vendor is like hiring an employee. You want to give them your trust, but need to verify that they are not cutting corners. Use the spreadsheet to see if they are on track. If they are behind, have a frank discussion and come up with a plan to get back in the game. Building software is working with humans.
But if you feel they can't keep their promises and every sprint review is a disappointment, the spreadsheet will give you all the tools to stop the collaboration early. Don’t waste money on a vendor that can’t deliver.
While we all love agile software development and product management, working with an external vendor forces us to brush up on our project management skills. Especially in the tricky fixed-budget scenario, there is a big chance of overshooting the budget.
While I believe in working with vendors you can trust, a good project plan will help you follow up and intervene when things start to go south.
Fixed-budget without project management is carte blanche.
You really don't want that.