Fixed scope, fixed budget projects and agile development

It may sound too exaggerated to be sensitive about this question and to deal with it so seriously. But the underlying assumptions from which the question arises are fundamental and very important success factors for the project and the product. It is also not a unique issue for website development only. The issue arises in every R&D project where creativity is important to achieve a not yet defined outcome and therefore not yet known needed input.

If it (the outcome and the needed input) is already known, then the question is completely justified and easy to answer. But the nature of software development has long been proven that it simply is not possible to know the necessary input to verbalize it in advance. (We can’t even formulate it, if we were able to know it. Something with UML and stuff ) The only smart thing to do is, writing down high level requirements so that both input and output can be just in time determined by the person who is developing it.

Other solution is not using custom developed software but using an off the shelf solution (with some modification if needed). Actually, this is the most advisable and best option if it is possible. But keep in mind that the expense of an increase in component integration work and the license terms can mean trouble.

How should we deal with suc a question?

It is actually very simple. The only thing that should be explained carefully and patiently is that it is honestly difficult to estimate (with a precision that still makes some sense) how much it will cost because there are a lot of factors that will determine it. Especially the interpretation of how features will be functioning exactly, and the quality (security, reliability, scalability, absence of bugs, extensibility, maintainability etc.) is almost impossible to negotiate about and sign a contract for. And these are precisely the properties which make the product successful or not.

Explaining that by determining as much as possible upfront will only result in a bad product. By making legal arrangements, the customer will only suffer from disadvantages, like not being able to change the requirements and the final product is no longer what he wanted or needed.

What does the customer want?

When there is a customer and supplier relationship in a web development project, the customer want to ensure that:

• The features of the website are as intended (scope)
• The website is working as expected (quality)
• Using minimal amount of resources (cost and schedule)

To achieve this, the typical customers strategy is to make sure that the project constraints are as fixed as possible. But fixing things in a dynamic and uncertain world is very difficult. Uncertainty principle is very simple: certain pairs of physical properties cannot be simultaneously known to arbitrarily high precision. That is, the more precisely one property is measured, the less precisely the other can be measured. In short, it means that by the amount of fixing the budget and scope of the project, the quality will become increasingly uncertain.

As a result, suppliers will commit to do the development knowing that the only constraint that they can adjust without consequences is quality. But everybody knows that decreasing software quality is the dumbest thing you can do.

But the unintended consequence is not only the suffering quality. It is also formally or informally agreed that:

The scope of the project cannot be changed anymore without changing the contract conditions and the project budget.
It is statistically proven that the project is still unlikely to be delivered within budget or that the deadline will be met.
A lot of customers out there have been burnt by unrealistic offerers who fail to deliver as promised. The IT industry has an exceptionally bad reputation when it comes to meeting the fixed budget and scope agreements.

Another side effect is that by asking a fixed budget the analysis and requirements gathering time will increase exponentially. A typical waterfall web development project will spend 30% of the budget on analysis and specifications. Knowing also that these documents are already outdated before the realization even begins should make it obvious that it is really wasting resources.

Conclusion

A project has many constraints but they are often simplified to 4 popular ones: Scope, Cost, Schedule and Quality. These constraints are often visualized with the “Project Management Triangle”. This model should make it clear at a glance that changing one property affect others.