We are a small company developing custom software that typically implements some business critical function. Actual back-ends with lots of asynchronous transactional business workflows, mass-data processing, integration with other back-ends, machine-data and shop floor user interfaces.
We do not design or implement this software from scratch. We have tools and a solid software foundation and experience to analyze business processes, map them into software and eventually implement them. That’s what we bring to the party.
We do in general not do fixed-price projects. We do not do that because – in general – that simply does not make sense – not for us, not for our clients.
This post is on why asking for a fixed-price project is more often than not the wrong thing to ask for, for us as developer and for you as client. It is on why you should not want to contract a developer for a fixed price project and what you should do instead – to make life better for you as client and us as developer.
Normally you will read that the very first step of any software project is to develop an understanding of the actual business problem, its essential data relationships and what users will need to solve it using a software system.
And indeed, while there will be an initial problem description, it is not necessarily describing the problem to solve in terms that map easily to a technical solution approach. So you need to create a more technical and fundamental formulation of the business problem to solve as to create a foundation onto which the project can be planned and implemented.
However that is not the whole story. When you are at that point, you are already in the project. Another indispensable step that comes first is to build ground for common trust between client and developer.
Why would a client trust a software project that potentially evolves into a multi-million euro endeavor to a developer based on an exchange of design ideas and some vague planning?
Why would a software developer risk expensive litigation because of a misunderstanding of what a solution to a million-euro software project is supposed to deliver based on a design that turned out to be wishful thinking?
Navigating the Timeline and Securing Success
I believe there are three essential (moving) meta-milestones in any project:
Next: All the features and fixes you know are needed and of which the developer knows (or believes to know) how to do them right. Everything in Next can be done now.
Near: All those features that you believe could be done down the road, possibly relying on the Next, that you think would be really useful to have but you are not sure you are really willing to pay for all them just yet nor is your developer certain how long it will take and how well it will work.
Far: The vision of what could be done, if you had the Next and some of the Near, and maybe some cool idea and the right business framework. You would not know how to plan for it now, but sharing it provides orientation of where, eventually, we want to go.
These moving target meta-milestones define the grounds on which to repeatedly plan and commit. By agreeing on them, we build a common understanding on how we believe the project is to move forward – while committing to the next “realistic” fraction of it:
The Near defines the Next by showing you the boundary of what you feel sure about. The Far on the other hand guides the creation of the Neart and the vision to communicate when justifying the effort as a whole.
While working in the Next, the Near and the Far become clearer – ideally Near flows into Next and there is constantly food for work and success in the project.
Here is the deal however:
- While agreeing on the Near and communicating the Far, you only contract on the Next.
- While working on the Next, you fill it up again from the Near.
- You make sure that splitting up, while not desirable, leaves no more burned ground than the current Next.
As potential project partners, developer and client should agree on a first set of a Near and Far. I tend to call them Phase 1 and Phase 2, as that is probably more expected. As the first thing to do however is to come up with an initial high-level design or even somewhat of a specification, that would exactly define the Next.
And that is what should be the first commitment.
The result of the specification will be an understanding of a refined Next, Near, and possibly an updated Far as well. The goal posts will have moved, and you can move forward into the next iteration: Actually implementing the Next.
Speaking in agile development terms: An iteration here is generally not a sprint, but more likely multiple sprints, depending on the size of the project and the planning horizon. You would nevertheless align budgeting and mid-term planning with sprint boundaries as to not interrupt work unnecessarily.
At any time, you make sure that work has been specified and documentation has been updated to the extent that work can be passed on if required.
As a developer, you know that everything is set and you do not have (unexpected) technical or documentation depths that will haunt you later on.
As a client you know that there is no unnecessary dependency that may mean that you lose control over your asset.
In particular this means:
- Contracts do make sure that anything developed belongs to the client
- If necessary, the client can continue development with a different team, bring in new developers, move development in-house, if that is desired.
The latter means that project organization tools and content, development and testing infrastructure is either already operated by the client, comes with the project, or can easily be re-created by the client.
It is naturally best, if development and testing is inherently contained with the project sources and mostly independent of other external or proprietary tools.
In order to maintain trust versus the project and in you as a developer, you should make sure to manage a well stuffed backlog for the Near so that continuity of the project is preserved.