Ivesia Solutions Inc

Fixed bid projects are characterized by fixed time, predefined scope and fixed budget. Add to this, predefined quality checks. We will keep quality out of consideration for it can be never be considered a variable. The other three (time, scope and budget) can be considered variables. In most fixed-bid projects, none of them are allowed to be variables, which more often than not, lead to the project not meeting the expectations of stakeholders. Having all three of time, budget and scope fixed is very unrealistic and will most likely result in project failure. However, if we can change one of the variables, it will certainly increase the probability of success.

For the likelihood of project success to increase, it is acceptable to change one of the variables. When it comes to Agile, which is synonymous with change, scope is allowed to change. If the scope changes, what is so fixed about the project?  This is a good question and this challenge has to be overcome for fixed bid projects to be done using Agile.

How do we address this challenge?

At Ivesia, this is how we do it:

1. If scope change comes too late in the project, then it is better to re-work the SOW instead of squeezing the scope change, for it would even affect the design of the software.
2. If the scope change comes in the middle of the project, we accommodate the changes by pushing out low priority items of similar size. Many a time, it becomes difficult to identify items of exactly similar size, but a 20% difference should be good to go.

Essentially, agile and fixed bids can go through if there is an implicit understanding between the customer and the provider that there can only be so much allowance in scope change and replacement of low priority items against high priority changes, without affecting the definition of a working product.