The Patient Workflow system worked without flaws, and we were able to process thousands of patients right after launch” –- Mathias, PM of Pairing’s client
I can recall when I got into one client projects some years ago. They hired me as a fractional CTO. The project sounded like a month of solid work for a pair of developers.
When I made an inventory of the code I found that 2 developers had worked on it.
2 freelancers, actually.
The first charged 12k EUR and didn’t complete the project.
The second said that the code of the first was really really bad, he had to write it again in emberjs. He charged 25k.
And you can guess it: he didn’t bring it to production.
A budget that’s 3x overdrawn – and not even shipped.
If you think that’s a rare case – just look at Wikipedia. There’s a huge list of failed projects (see wikipedia). Exemplas like canadian government that failed to migrate their websites to a new system and went over budget threefold.
And these are only the publicly known cases where clients had to pay way more to get the planned functionality (not even counting in the delay). Private companies probably have a similar failure rate, and then fold a project and never talk about it again.
You might thing that developers are just bad people without self control who only want to build fancy stuff and don’t give a damn about you reaching your business goals.
And that’s true!
Developers have enough on their plate. They need to attend meetings, design features, and foremost: write code that doesn’t break.
How great would it be, if you’d find a way to actually ship a project within budget? You’d be able to get a higher ROI on it, probably launch faster, and then have more money left for advertising (thus increasing ROI again)
Ever had a crisis meeting with a software developer who told you that things will take longer and cost way more than initially thought? In a way it’s understandable – the developers only have the best intentions. But in the end: YOU are the person paying for it (or your boss, which might be even as bad).
Does this sound like a memory from your career? Are you managing developers or owning a software product and have failed getting it done on budget – maybe repeatedly?
Then this essay might be a start to turn things around and finally stop overpaying on software development that never finishes.
The remedy is like a bitter pill to swallow.
People don’t want to hear this. But it has to be said.
The better you specify a project, the better chance you have to get it within budget.
We shipped the project within 3 weeks, and it worked right away. — Lasse, client
Scary new concept 1: Embrace Deadlines and Dates to Ship
Deadlines do two things: they define a clear date to ship. And they normally also define a clear feature set to ship. And as they define a clear date to ship, they also put a limit on the cost.
See our case study of the Passport Access System. We did a lot of overtime, but as the deadline was clearly specified, there was a high chance of staying on budget. The overtime was just inside the error margin we put into the calculations.
The deadline was the one thing everyone could hold on to.
But not just that.
We also had a clear feature set we needed to shop – else the access pass system would not work, and hundreds of thousands of people would wait in front of the website and blame us for not getting their passes.
In the software development industry, time and material is usually the business model of how contracts are made and how services are delivered. This means that with a clear deadline, you automatically put a cost limit to your project.
It’s pretty easy to understand: if you pay – let’s say 10k EUR for a developer per month, and he works a month, then the price is 10k. It could be 12k if he works overtime. But if you give him 2 months, then suddenly the price can get up to 24k.
“What if you just add more developers, and thus costs explode?” Well – that’s normally not happening. Adding more developers doesn’t make a project go fast, just as adding another woman to pregnancy doesn’t help the baby come out faster.
We at Pairing believe in Pair programming. So yes, the second developer adds a lot of value. However, for a small project with some pairs already working on it, adding another pair normally doesn’t speed up the project.
Scary new concept 2: Plan every feature to develop and ship
Seth Godin built and sold Squidoo. I cannot find the piece any more, but I can recall him saying that he got the initial version of Squidoo built out within budget by just specifying it out completely:
- He looked at every button and what would happen after every click.
- He designed every screen, every modal, every message.
- He went through all user types and specified the users journeys
This comes from my memory, as I cannot find the podcast episode any more (got it for me? Send it over please: till@tillcarlos.com).
Sure, specifying is important. Everybody knows this. What most people get wrong is the degree of detail to which you should specify a feature. Let’s give some examples so you see what we are talking about:
But what is a good degree of detail?
Let’s imagine we want to build a simple customer support widget. Mind you: this is not a UI spec, this is a functional spec for the developer. We leave out the UI at this point, to make it simpler.
State specifications
Specifying all the states the user can click through.
User roles specifications
Let’s assume our widget is part of a backend software where people log in. Do we want them to enter their email again? Let’s make it easier for them.
- User: visitor: sees the widget as specified in step 2
- User: logged in: It pre-fills the email address.
- User: Administrator: don’t show the widget at all.
Those are incomplete, but you get the idea. Often people miss roles in their specifications.
Process specifications
What happens in the background?
There are many ways this can be specified, like flowcharts and process diagrams, and often they make sense. Important is: it’s written down in plain language:
- What happens when the user takes an action.
- What happens when the system triggers an action
- What outside events can alter the state of the user journey, e.g. losing connection etc.
Just to give you an idea of how this can look like when no specification framework is used.
How confident can I be that their estimations are actually correct?
From our experience, there are only 3 cases where developers estimate software wrong:
- Features (scope) gets changed along the way. \ We mitigate this by writing good specifications.
- They are not skilled enough. Juniors tend to estimate lower. \ We mitigate this by hiring better developers.
- They don’t know enough of the business case. This is where basecamp comes in with a great visualization: the hill graph.
What you don’t know what you don’t know: the hill graph
Read this chapter in “Shapeup”. Basically it shows you what happens inside people’s brain when they have to estimate what they have no clue about: it’ll most of the time go wrong.
Sometimes you cannot mitigate this estimation risk completely, but you can try: get developers who have the most understanding of a certain business case. They will move over the tip of the hill faster and come back with better estimations.
Scary new concept 3: Constantly monitor development progress
Content monitoring, every day. That’s why we do sprints and daily standups. In case we find that we are not staying within budget we can cut features, so that we can ship something that works, and which is in the budget. — Bilyana, PM Lead of Pairing
There has been a lot of research done on daily standups, because they are done a lot. Read martinfowler’s blog for a very comprehensive list of tips and resources.
How do you best monitor a software developer?
You do daily standups. You get together in a quick meeting and everyone answers these questions:
- What did you do yesterday?
- What are you working on now?
- What challenges and blocks do you have?
We at pairing have some teams that work in a different way: we do a digital, asynchronous standup – which works in the same way: we post in our discord channel and answer these three questions.
Can you have standup meetings and still not control the process?
I think we have all been there: feature bloat. Often managers add functionality as they go through the sprints. A feature that looked small in the first version slowly gets bigger because some edge case was not defined.
This is where we need to go back to step 1 and make sure that everything is defined.
But even then it’s possible that developers have issues but don’t get the voice to share it. This is human. People always think they are “just about to figure it out” and then something takes another day.
We at Pairing do this. We built checks on the progress into our Pairing work:
- The Technical Analyst gets to review code, discusses architecture.
- Thus he directly sees where the Software Engineer (the other person in the pair) could go wrong.
- They discuss the issue and change course if needed.
Takeaway: when you have a technical person as a manager or as a sparring partner for your developer, you will have an easier time monitoring them.
How to ship software within budget: a conclusion
Having a project stay within budget requires you to keep an eye on all these 3 fields:
- Deadlines and definitions (You as a product owner)
- Estimations (Together with an experienced developer, or Pair)
- Constant monitoring (with someone who understands developers)
For all projects that we shipped within budget and time constraints: all these three fields have been well covered.
This essay was written by me, Till, the CEO of Pairing. I asked our PMs for their input in order to write this up.If you have questions about this content, please reach out to me on linkedin or via email. I’m always eager to discuss software projects and learn from your experience as well.