Something to think about as these might not be the first that come to mind but are nevertheless important issues affecting the project in the long run.
(Traditional) Fixed contract — contract that contains the whole price for the project and a list of functions it must have.
- Change Requests (CRs) are priced without any competition. CRs can easily become a major part of the project’s price. A traditional contract can in fact be very lucrative due to CRs and even be the basis of operations for companies delivering projects.
- Over time, rigidness of a project increases and affects the ability to change direction no matter how it is delivered, either with a fixed or flexible contract. It is, however, always important to change direction as soon as possible while the project is easier to shape. Change Requests slow down the implementation of changes as negotiation over them usually takes a long time.
- Documentation is not created for the good of the project but as a contract requirement. No documentation is usually bad but writing useless documentation is wasteful.
- Issues are tackled due to fear of breaching the contract and should be because of wanting to create the best product.
- It’s quite often difficult or even impossible to change the ethic of a company if the contracts stay the same. How employees interact with each other and deliver products is often dictated by contracts. And with them fixed, there’s a risk of falling into a “it’s not my responsibility” ethic and facing “developer silos”, since following the rules of the contract takes precedence over the quality of the product itself.
- “Big bang” approach to releases and independent phases. Most significant problems tend to occur between phases, at points where one group in the company passes the project to the next. For example, developers might work on a project for several months and then pass the results to the testing team. Results are not visible early, the system might be in shambles during most of the development period and parts of it come together just at the very end.
- Many popular statistics take the implementation within time of the initially defined functions as an indicator of a project’s success. But a project that’s on time and with those initially defined functions might be far off from being successful when released.
- Giving a time and cost estimate after listening about an idea for a project for half an hour or reading an RFP is unprofessional and irresponsible. An indicative and non binding fixed-price range-estimate how much a project will cost by assuming a rough scope, might be a good enough start instead.
- When a project fails, the contract will be the definitive source of information about who should pay the price of failure (or additional costs of fixing the project). But, it should be the responsibility of both sides to make sure it doesn’t fail, that everything is well defined to minimize risk and tackle problems quickly.
- Negotiating skills have a major impact on the contract, specifically who takes the majority of penalties if something goes wrong. Usually, we end up at a lose-lose situation, where both parties gave up something they didn’t want to and are not completely satisfied even before anything gets done.
- "By how much the price of the project can go down" is a common strategy that’s not project-oriented. The project’s price may be justified and lowering it will decrease the quality of the project in important aspects. It should not be the only reason a company wins a tender.
- A safety margin will be added to the price. A standard is 30% or more of the estimation, irrelevant of how the project goes.
- Focus on local and not global optimization. It’s very common that corporations have a standard template for contracts. Information inside may have been influenced mostly by a narrow group of professionals in the company, presumably lawyers. While it is important that their expertise is used to write a contract securing the interests of their company, it might also negatively impact the project as they will locally optimise the contract, meaning based on their best judgment, and not globally, so that their company as a whole would optimally benefit from it.