How to manage expectations in software projects

We have been very busy in the last three months pushing sales. We want to kick 2024 in the butt to have another phenomenal year, so I haven't had time to write more articles.

Here's one I wanted to write for a long time, about how to manage expectations in software development projects.

After 150 projects and almost eleven years, we have learnt a thing or two about managing projects. At least, I have. I want to share my own personal learnings after managing projects in different capacity, for both startups and corporates, for big brands like FC Barcelona, Ford or Citadel Securities, in all sorts of shapes: team augmentations, full-outsource, retainers, fixed bid, on-demand and bank of hours.

Alright, let's start!

Always ask 'Why?'

Start with curiosity. In business, understanding the 'why' behind actions or decisions is crucial. It's not just about the task at hand, but the purpose it serves.

In practice, this means asking why have specific deadlines been set or why hasn't the budget been increased from last year. In my experience, a lot of these business decisions happen to be arbitrary, so if you don't question them, you will be subject to them blindly.

Most projects come to us with a pre-defined deadline. I always ask why at the beginning of the project, and in most cases they're either wishful thinking or a soft-deadline. Most of the times, they come imposed by business but they're not sustained by any kind of technical foundations, so I am able to negotiate the deadlines (or budgets) just because I've asked why. A lot of the times, they just answer something like "well, the deadline isn't 100% fixed, but we'd like to have something for that date".

We just went from having to deliver the whole project to something with only three letters: why?

The same happens with budgets. A lot of the times we get something like "well, this is the theoretical budget but we have got some extra resources for deviations and last-minute additions to the project".

Deadline type matters

Deadlines aren't just dates; they're commitments. Understanding whether they're fixed, flexible, or aspirational can transform how we approach our projects.

I have briefly covered this in the previous point, but I want to double down on this specific topic here because deadlines and budgets are the elements that create most friction in projects.

Deadlines are always self-imposed. No one is going to die if your website isn't launched on May 14th, Frank. If you launch it by May 16th and your business goes down the shitter, chances are that you didn't have a good business to start with.

Look, certain deadlines make more sense than others. Rebuilding your whole e-commerce and plan to launch it by the next Christmas campaing isn't just a bad idea: it shows your team that you have no idea of risk management.

If you want to rebuild your platform and it happens to be an e-commerce, do it gradually and do soft-launches around low-sale seasons. Have all your big launches planned for weeks, if not months, before big dates like Black Friday or Christmas, to ensure all goes to plan, or to have enough time to roll back and operate with your current platform.

Certain deadlines, however, do matter. For instance: your platform runs on X technology and the current version won't be supported anymore next year, or a certain regulation comes into place in 24 months and you have to completely change the product. In both cases, these deadlines are immutable, but they are always months - if not years - away, giving you plenty of time to do something about them.

In the case of support being discontinued, this is like a warranty expiring: it doesn't mean your platform will break on day one of no coverage. The chances of that happening are very small but it's understandable that you want to have your back covered. A few extra days to launch the new version won't do any harm, or you can always launch earlier with fewer functionalities or a fraction of the users, to test the waters before rolling out the whole thing.

Look, I won't lie: sometimes we don't meet the deadlines. Some times we've been too optimistic with the estimate. Other times, the client messed up delivering something really late or adding too much stuff last minute, and in all of the cases, the same thing has happened: nothing.

Not a single time in over 150 projects we've seen a drastic consequence following a missed deadline.

In fact, people miss deadlines all the time. During the sales process, we might send the estimate one day too late. Contracts and NDAs are always signed later than expected, and projects never start when they're supposed to. When clients say they've got their API and designs ready for us to start coding right away, in most of the cases that's a lie.

On November 1st, we had to start two new projects. One of them was already signed but their team didn't become ready until December 15th, so we started another project and now we agreed to delay the start to January 15th. No damage done.

The other project is yet to be signed. In fact, in June we got an email cancelling one project that we signed one year prior but we never started. Turns out, this client pushed back the start date for a year, one month at a time, until it didn't make sense anymore to do it. We sighed and carried on with our lives.

Be water, my friend

Flexibility is key. Adapting to changing circumstances while maintaining our core values is essential for navigating the unpredictable waters of the tech industry.

After learning that both deadlines and budgets aren't always immutable, the next thing is adapting to changes.

We have learnt in many ways that all projects might be hit by something unpredictable: a priorities change, layoffs, a funding round that didn't go through, delayed payments, and more. Sometimes, we have had to pause a project for a few weeks. Some of them were never resumed.

That's why we have never had all of our eggs in the same basket. We try to have as many fallback plans as possible, especially around the big projects.

Small projects don't need fallback plans: if we lose an 8-10h/week project isn't a big deal. We will most likely reallocate the dev in another project, or we can get a new one of the same size relatively quickly.

Big projects, instead, are trickier. What happens if you lose a 5-people project overnight? Well, it's not easy to distribute that team into other projects. First, they need to be a match in terms of technologies, but second - and most importantly - that client might not have extra budget right away for an extra developer or two.

To mitigate these situations, we have a lot of cash in the bank to be able to pay salaries even when our developers lose their projects, giving us plenty of time (usually 2-3 weeks) to find a new project for them.

Actually, if I had to summarise this section in a sentence, I'd write: be flexible about being inflexible.

Add margin

People don't like when you tell them that you add extra margin to fixed bid projects. They want you to be extra accurate with the least amount of possible information they can give you.

The reality is: all projects need margin. Margin can be used to unplanned features, deviations on either side of the project, integrations not working as expected, a deadline pushed back, etc. Margin is a life-saving asset for not only the provider, but also for the client. That extra margin will allow us to go the extra mile when it's required, and we will be more likely to renew our commitment. Take away that margin from the get-go and the message you're sending is "I don't trust you".

Look, if you put too much margin, the estimate won't look right and you will lose the project, so we're not incentivised to inflate our margins to milk your budgets to the last drop. We want this to be a healthy relationship, so let's allow a bit of elbow room for misunderstandings and unplanned circumstances.

Always plan for the unexpected. Whether it's time, resources, or patience, a little extra can go a long way in ensuring success.

Give daily feedback

We have all heard horror stories about development agencies stealing client code or never delivering the project they were hired to do. As it's the case with most horror stories, they're greatly exaggerated every time they're told, so the version you've heard is so far from the original one that they don't make sense anymore.

However, projects tend to fail for one specific reason: lack of communication.

We send weekly reports, on Mondays, to our clients stating:

• What was accomplished the week before.
• A recap of the hours invested in the project (sometimes broken down at task-level).
• A forecast of the team availability (holidays, sick leaves... and changes of capacity).
• Screenshots of the latest developments.
• Blocking issues.
• Where we sit in terms of budget remaining.
• Other important issues the client ought to know.

With that, we come into the weekly meeting to discuss what wasn't understood or aligned instead of reading status reports. The meetings are more meaningful and because we provide a weekly re-calculation of our estimate, there are no last-minute surprises of deviations.

But... that's weekly, not daily! Why did I write daily in the title?

Well, because when things go well, less communication is needed. However, more often than not I resort to daily pings to people lagging behind to check up on them. For instance, when the client isn't delivering the mockups we need or the API endpoints that are blocking our developers, I nudge them daily by sending reminders, scheduling calls on Slack or trying to help them to unblock that particular issue. It sounds bothersome, but it shows you care about the project. It doesn't hurt to remind them that we might want to bill them for the time they're preventing us from progressing. That usually works like a charm.

Communication is the lifeline of any project. Weekly check-ins keep everyone aligned and daily nudges for specific critical issues can go a very long way to resolve blocking situations and prevent friction.

Renegotiate

Negotiation is a skill that's hard to acquire. Some people are natural-born negotiatiors, some we have had to learn it along the way. But there's one thing harder to learn than negotiation: renegotiation.

Technically, they're the same thing, but in actuality, they work differently.

During every sales process, there's a negotiation window. Both parties try to hold positions on budget and dates without giving up too much to ensure their commanding position. In my experience, projects with strong negotiations tend to do better over time because all potential issues were covered upfront. In contrast, if there hasn't been any kind of negotiation in the sales process, you can expect a lot of nasty surprises during the project.

If a project starts having too many unplanned issues like changes of roadmap, heavy team rotation, third-parties not delivering or other circumstances affecting the deliverable, you might be facing a renegotiation.

In the last four years, we have had two big renegotiations because we had two big delays with two massive projects we participated in. In one of the cases, we had been overly optimistic with the estimate partly because the client didn't want to give us access to two parts of the application that turned out to be a very complex nightmare. We decided to split the responsibility between the two parts (not 50-50), we renegotiated an extension to the date in exchange for a lower rate, and we continued doing the project. The renegotitation talks were serious but never tense, and we ironed out all differences with daily/weekly check-ins, and the project turned out to be a success.

In the second case, it was entirely the client's fault. We were promised one part of the application that was "working flawlessly", which turned out to be entirely untrue. We wanted to keep the project and the client, so we decided to take it up the chin and split the responsibility in this case in exchange for more projects to compensate for our loss over the years. We signed a multi-year agreement with a higher fee and we solved the issue.

So, as you can see, negotiation happens at first, with a lot of unknowns (and unknown unknowns) and between C-levels and/or sales teams, but renegotiation usually includes everyone involved in the project. In fact, in order to re-negotiate with the client, first we need to re-negotiate internally with our own team, before coming up with a conciliating solution that will work for the client.

Negotiation isn't a one-time event. It's an ongoing conversation that reflects the evolving nature of our projects and partnerships.

Conclusion

In conclusion, these tips aren’t just words; they’re the essence of our approach at MarsBased. We strive for quality software never at the expense of being good people.

If this blog post performs well, we might record a podcast episode about it because we have many more examples to share!