Fixed Scope Software Project: Perspective of an Honest Vendor

Alex Cherednichenko

What is a fixed scope approach to development of software products? What are the main risks associated with it when examining the approach from a perspective of a client-vendor partnership? Alex Cherednichenko, Logicify BizDev, gives his honest opinion on the topic and discuses how our company addresses the challenges of fixed scope projects.

7 min read

So, you have a software product to create.

This product should solve an actual pre-existing business problem. There is a clear vision of what the problem is and an understanding of how it should be solved. Your thinking is that introducing this product would create extra value for your business. The product is not exhaustively specified - there is no 200-page spec document, which is the case for an absolute majority of the projects out there.

Chances are this is the first time you are building a product from scratch.

On the resourcing side, you do not have (enough) people in-house to cope with this project, so you look around for a software services company that could help you do it. In this setting, you are the customer, and the service company is the vendor.

Full disclosure: I am a founder of a software services company called Logicify, and we see many projects of such kind. Just like in a setting above, we help our clients deliver their amazing products. I wanted to share my views and experience in this type of relationships and lessons we have learned over time at Logicify about making projects succeed.

Software Product Development in an Ideal World

Let's look at an ideal situation first: the customer's understanding is full and exhaustive, engineers are qualified, and information is not lost while translated from a person to person. In an ideal world, the most effective setting would be to get the right team of people with relevant skills, connect them to a proactive and efficient product owner, and let them actually do the project. No distraction for time accounting, reports, and unneeded meetings. This is the real idea behind Agile, I think. Product Owner understands well what is really needed and what is not. In an ideal world, you would have your own team working for you - motivated, professional, and available. In a little-less-than-ideal world, you would have the same team working for you on the vendor side, a so-called Dedicated Team.

This is the best possible approach for the Agile: get the right team and don't distract them - and things will be good. Things will keep improving as the time goes.

Software Product Development in Reality

Reality is very different from the ideal world. Having an exhaustive specification might take up a half of all work. When you know exactly what should be done, the easy thing is left: making it.

In real world, competences are not always good, product owners are not always available, things keep changing all the time. Engineers are not always knowledgeable in the specific domain area, technology does not always integrate well and behave as expected. Unforeseen findings might also delay the whole project delivery. When you are in this situation, you need to have the product - this is the ultimate goal because that is where the value is born. The 'project' is just a way to get to this goal while minimizing losses and getting intermediate information to make decisions.

Fixed Scope: Defining Everything in Advance

So there is a risk of the project being not completed on time. An objective one, hiding in the unforeseen technical complexities or external changes, and a subjective one, born out of misunderstandings, different domain and cultural context of participants.

There is an absolutely normal response to approaching this risk: you, as a client, can think to fix the scope, budget, and timing in a contract with a vendor. In this case things seem to be good: you don't pay for the product until it is ready, you have a clear acceptance, and the indigenous risks (if they fire) are on the vendor. Life becomes beautiful again, eh?

Issues of the Fixed Scope Project

There are issues with the fixed scope, however. I tried to highlight these issues from a perspective of a client-vendor partnership. Yes, I believe that working in a philosophy of partnership is where the efforts get aligned and the good business is done, so any inefficiency is not an added margin for someone. It is a loss for everyone.

Here are the issues:

  • Risk is not shared, it should be allocated to any of the participants. Knowing this, vendor naturally takes measures to include some buffers to stay within the margin.
  • Working together becomes a competition because of the previous item.
    • Vendor's goal here is to be able to deliver within their margins. Any added work is not wanted, simply because it pushes budget down.
      Profit = ContractPrice - Hours * HourlyRate - Inefficiencies
      Whatever added work (hours) get there, it pulls the profits down, so the natural way is to push as much stuff as possible out of scope
    • Client's goal is to get as much done within this fixed time and budget. So whenever it is possible to define the unclear bit in the specification in a way that gives more value, this is done.
  • Changes are a problem in fixed scope. Ideally, when the change is requested, the vendor would do the re-estimation and propose a difference in a project plan, and, if it is good with the customer, so it goes. In reality, though, the change management procedure is expensive by itself - administrative overhead. Engineers need to spend extra time estimating and understanding the overall plan change, someone needs to spend time on researching the requirements, and some time needs to be spent on negotiating whether (and how) to include the change, up to the changes in contract or addendums.
    Not like the product research is not needed in all other processes; it is that change management in a fixed scope gets pure overhead on administration.
  • Business pivot is not possible; it would mean an entirely new agreement, product, process, etc.

The real big, most important, problem I see in this setting is that it is far from being efficient. If the team assigned to a fixed scope project can deliver it in fixed scope, it can do the same in a dedicated team mode but with a few overheads (more effectively). If the team can not deliver this product in fixed scope, there is not much to be recovered. For smaller projects, suing the vendor is economically ineffective. For the big companies, even if the court rules the damages and the contract amount be paid back, that would never come close to the economic effect of the software should it been there - why would you order it otherwise?

Fixed scope is a good take on a problem, not the best though. The business, however, is built on trust and goodwill and previous experience. Costs and importance of the software are too high to lose.

Fixing the Fixed Scope

I think there are ways to fix this, or at least mitigate some problems.

  • The best: to start with a small fixed scope, and, if you are happy, switch to a dedicated team to build and nurture trust in a dedicated team.
    In this setting, the small part is at risk, and, when the confidence is there, the whole process switches to the most effective dedicated team mode.
  • Make a separate 'specification' phase done before with the vendor you think of going with. Scope and price it separately and have it produce design documentation and spec — this is what we do with architects when buildling a house. You can see if you are content, and, in the end, you are going to have the most important document - the spec:
    • You can send the spec to multiple vendors to make it a proper RFP process. Most of the RFPs we see are not documented to a level needed to devise a right estimation. If you have a detailed spec document, chances are the bids would be more accurate.
    • While making the specification, vendor might need to do some checks, make up quick prototypes, wireframes etc. These have a value in themselves.
    • With the specification, many helpful things can be done, like specification testing.

How We Solve These Issues at Logicify

As every company in software services business does, we also face these issues.

At Logicify, we work by building effective and motivated distributed teams, and we build the trust over time. We do not like inefficiencies as someone has to pay them, and, in our setting, whatever our client spends extra is as bad as we pay extra ourselves. We always aim for an effective dedicated teams; however if the fixed scope is the only option to go, we get into the specification phase first.

If you like to know more about what we do, drop us a line at if you are up for a next world-changing project. The views here are just views. Comment on this article, or email me to for a more personalized discussion.

Related articles


Scroll top