It’s easy to default back to a waterfall way of thinking when we’re running fixed-priced projects. As a business delivering a digital project, we need to capture the entire scope of the application to protect ourselves from scope creep later on. Because scope creep in a fixed-price project can get expensive, with a capital E.

So, we start off doing our discovery work. Talking with the client. Investigating the systems that we need to extend or interface with, and reading any documentation that the client can provide us. Once we’ve done our discovery and got an understanding for what it is that the client wants us to build, we put together a software architecture document that we can present to the client and use as our statement of work. Right?

Wrong.

Let’s take a step back for a moment and think about the all important word in the title of this article - Agile. We may not be running a strictly Agile project, but we still need to be working inside the processes and frameworks that Agile teaches us as software developers.

The first problem arises when we give a software architecture document to developers and expect them to use it to build out the features of our product. For us “older” developers who were around before Agile was a big deal, it might be ok. But a lot of developers who have grown up in Agile won’t be familiar with this - they’ll be used to planning sessions and tickets in Jira with acceptance criteria that they need to work towards.

You’ve also got the issue that, as requirements change during the project’s lifetime (and they will) or new information comes to light, you’ll need to go back and update your document, then distribute a new version to the rest of the team, highlighting the elements that have changed.

I understand completely that we need to have something to provide to clients that outlines what we’re going to be building, and how we’re going to do it, but that doesn’t mean that the initial starting point should be a software architecture document.

If you have a development team, chances are you’ll be using some sort of board and ticket system to handle your feature delivery, be that Jira, Azure Devops, or something like Basecamp. So, why not leverage that to scope out your fixed price project before putting a statement of work together?

There’ll be no difference when mapping out requirements in a fixed-priced or agile project. We still need User Stories, and the subsequent tasks that come out of this. My advice is start building your features in your board before you put together the statement of work. Involve your development team in the scoping out of these tickets as part of the discovery process (think of it as a longer sprint planning session). Get the input of the people who are going to be building the application - the more eyes on the scope at this stage of the game, the better prepared you’ll be when it comes to reducing risk later down the line.

Your boards should always be your single source of truth on a project. If we have all of our stories broken down on the board, instead of tied up in an often unwieldy software architecture document, then when we get changes to requirements or new information come up later on, we can update the tickets with comments and attach the relevant documentation. This way, everyone knows where they stand.

That’s not to say that you shouldn’t have a written statement of work - you need one to outline what you’re going to contractually provide. What I’m saying here is that it shouldn’t be the main source from which you’re working as you develop your application.

Waterfall has gone out of fashion for a reason. If you’ve worked in it, particularly back in the late 90s or early 2000s, you’ll know why. It’s acceptable to use when your project is short, and when the application that you’re building isn’t overly complex. Yet you’re left running all of your tests at the end of the project, clients can’t really see anything whilst you're in the build stage, and you need to add in a lot of contingency to your timescales.

The one thing I will say is that we should never confuse “fixed-price” with “waterfall”. You’ll have to follow a similar agenda, but we shouldn’t fall back to heavy documents and rigid phasing that are akin with the waterfall model.

What you’ll need to ensure is that you have allocated a sufficient amount of time and resources into the discovery phase, because you’re going to have to capture as much as you can. You will miss things, and requirements will change. That’s ok. You just need to make sure that you include this in your contingency time.

As I said before, get your development team involved early, and make sure that you run your UX and designs past them so that they can call out anything that might look ok in design, but that will turn out to be much more technically complicated than you’ll have initially thought.

Start scoping out on your boards, and use these as a single source of truth. Build your statement of work off the back of the tickets you put together in your project board. Personally, I would forgo with putting together a software architecture document - you should have everything the developers need in your tickets, and you won’t need to use it as part of your statement of work because this document should not be that technical.

Add contingency. I cannot stress how important it is that you don’t underestimate to win a bid. It will bite you in the ass hard if you do, and potentially damage your relationship with your client when the product that you promised will be done in12 weeks has crept into week 16.

Phase your features. Just because you're running fixed-price doesn't mean that you can't complete features and demo them in iterative cycles, as you would do with Agile sprints. This means you can get the client involved early and show off your progress.

If they change their minds about how something should work when they see it in anger. then you're capturing this mid-project rather than leaving all of their feedback to the end. And if they're adamant that it has to change to something that's outside of the agreed scope, then that's ok too - you can raise it as a change request, and negotiate additional time and cost for the project to cater for these changes.

All in all, never forget the tried and proven Agile practises just because you're delivering something where you're defining the entireity of the scope at the beginning. You just have to adapt it to make it work, as you should be doing for all of your Agile projects.