How much will it cost and when will I get it?

Whether we like it or not, eventually someone will ask the dreaded questions: how much? when? Or the variant: what can I get with this money? This post is my view on the topic; how would I start answering those questions.


  • I don’t claim that this post covers all the things needed to manage a SW project. It’s probably just a scratch on that topic.
  • There are principles that are common to SW industry, but on the other hand there are so many different setups and domains that one perfectly good approach could be just the wrong one in different domain. So I’ll just say it once so that I don’t need to repeat it constantly: it all depends.  Use your own head.
  • I stole the title for this post from this great post by Neil Killick. Read that, too. And his other posts.

Our example case

A customer approaches you. He wants to build an application. It doesn’t matter what the application does, but let’s assume a non-trivial application like health care system for a municipality or order management system for a retailer.

Before you even begin

Before I would even begin to think about duration and price I would try to figure out the following:

  • Does this project have to be this big? Could we divide it into smaller projects, pick a most important one, and start with that?
  • How much money is the customer willing to spend?
  • Have we worked with this customer before?
  • Have we worked on this kind of software before? Has anyone worked on this kind of software before?
  • Is the team that is supposed to work on the project worked together before?
  • What is the risk involved? What happens if this project fails? What is the profit that we’re expecting to get from this project?

There are of course many possible outcomes when you answer these questions, but here I’m roughly classifying projects into these three categories:

  1. Big project, new customer, new kind of software for you and failure isn’t an option. Example: pension payment system that has a specific launch date. Banking software.
  2. New kind of software, expected gains are big, but you expect to fail often. Non-SW example: new drug development. Mobile game development. Composing a world class hit.
  3. Something between the extremes. You may have done similar project before or are familiar with the problem domain. If you fail, someone loses medium to large amount of money. Example: online ticket reservation system.

Which of these categories does your project fall into? Is it more like…

  1. In this case I’d strongly suggest to have a smaller “test project” to have some kind of the feasibility of the project. Otherwise I would be reluctant to even start. Or you might just want to politely reject that customer’s request. Not your piece of cake.
  2. In this case I would not spend too much time trying create a detailed work plan. Just set a budget and/or schedule and start doing. You don’t even know exactly what you are trying to achieve, so why would you try to break that work into smaller pieces? In this case you need a experienced team.
  3. Rest of the post assumes that your project falls into this category.

Create a solution blueprint / concept

So someone needs to know “how much?” I would address that need by gathering roughly the following information:

  • Goal / “mission statement” for the product
  • Business case for the product. Someone is always interested in $$.
  • High level capabilities/functionalities for the product. What does it do? This breaks down the general topic of your product into smaller pieces of functionality.
  • Main user roles
  • Main concepts of the product and their relationships as a concept map
  • Interfaces to external systems
  • Initial idea of the system architecture

Usually you do this with your own money. If you can do this with your customer’s money as a first phase of your project, good.

If needed and requested, I would use this information to create a top-down estimate about the project’s expenses. I would use any information I have available, for example data from similar past projects and expert opinions. It’s been a while since I last participated in top-down estimating, but there are plenty of resources out there, like this list and this gentleman.

Based on the estimate I would come up with some kind of minimum promise for the customer: this is what you get, minimum. If we fail to deliver, we deliver the rest on our own expense. I would probably come up with “this is what we are likely to deliver” and “this is what we deliver if things go really well” lists, too, if applicable.

During the project

In general, I would start with the most important capability and seek to deliver working software from day 1. If not day 1, then as soon as possible.

As you take the capabilities into development, break them down into smaller pieces. We call them epics, you might call them features, or something else. You might want to consider classifying these epics into S, M and L size lots. Do this as late as possible.

Epics still aren’t the raw food of the development team(s). Let the team split the work into user stories in co-operation with PO. Prefer “can we make this story smaller?” -heuristic over story point or other estimation techniques. If your team wants to split the story into tasks, fine, but don’t ever estimate those tasks separately. In any case, if your stories are small enough, you probably don’t need sub-tasks. Do the story splitting as late as possible, too.

Let the team decide a process / workflow on how they are going to deliver software that meets the constraints that your organization and your customer’s needs impose. Visualize that workflow, for example with kanban board. Gather metrics about the cycle times and queues in your system. Do you know how long does it take, in average, that your story has to wait until it gets to testing phase?

If it’s a new team that has never worked together, start with a school book process framework. Scrum is a good option. Make continual improvements to your process, see what works for your team. Henri Karhatsu has written about his team’s progress. It’s a nice read.

Measure epic throughput and use this data to fine-tune the original top-down estimate you did in the beginning. You might consider using story throughput instead, depending on the size of your project. Use this constantly updated information to answer the questions how much? when?

Conclusions / my view on #NoEstimates

I claim that during development, you don’t need to explicitly estimate development efforts. You don’t need to estimate stories using story points and estimate how many hours does it take to complete a task. I don’t see a need for bottom up estimates.

You can, and maybe even should, however, use the actual development velocity metrics to forecast the future. You know how many stories does your epics contain in average, and you know how much is your story throughput. Use this data to predict the future. Some call this estimating, and I’m fine with it.

Some say “you cannot predict the future”. Sure we can, we do it all the time as human beings. We cannot be 100% sure, ever, but we can make the percentage higher.

One final note on #NoEstimates. One light bulb moment for me was that #NoEstimates doesn’t mean #NeverEstimate. I would be comfortable if someone called the above described approach as #NoEstimates approach even though it possibly contains macro level estimating.

Leave a Reply

Your email address will not be published. Required fields are marked *