Don’t be bullied by your procurement department—choose the correct engagement model with your service provider to give your next big IT software project the best chance of success

IT development projects are complex affairs. They are prone to budget overruns and delivering fewer benefits than anticipated. With so much money at stake, it is important that you, the CEOs and stakeholders of these major company initiatives, choose the right contract and approach with your third-party service provider.

Executives have a raft of contracting methods available to them, in some cases such as consulting engagements, time and materials might yield the best results, and for really clear and well-defined projects such as IT Infrastructure commodity projects, fixed price may be ideal. But for Agile Project Management, the right approach is rarely fixed-price unless it is linked to small, discrete, well-defined pieces of work. It simply doesn’t incentivize the right behaviors and outcomes, and executives would do well to ensure they have the right contracting model in place to support their project.

A report from the Project Management Institute (PMI) in 2017 showed that approximately 14% of IT projects fail completely; that number doesn’t even include the projects that exceed budget or under-deliver benefits.

Fourteen percent (14%) of projects fail, and many more exceed schedule and budget estimates

Adding the extra effort of negotiating and managing a fixed-price contract only increases the risk of failing on the other key tasks required for successfully achieving your goal (see Exhibit 1). If you are using a third-party vendor, consider that they normally can’t start work until a contract is signed, which can take many months to negotiate, tying up skilled resources that otherwise could have been getting the project up and running.

Exhibit 1: You must translate key project competencies into Agile Project Management working practices

Source: HFS Research, 2020

It’s a common situation. There is pressure at the senior level to adopt new technologies and keep the competitive edge or upgrade existing software. However, the appetite for risk is low. It’s human nature not to want to be the one that presides over your company’s first big IT financial disaster. So senior management start to introduce statements about going fixed price to “de-risk the project” and “transferring risk” in to the discussion. Except, there is no such thing as de-risking or transferring risk to your IT services partner. If the project fails, then the company has failed—regardless of who is responsible. Everyone loses.

Fixed-price contracts are predicated on knowing all the requirements and possible outcomes before the project starts. Really? Does your senior management and project teams consist of fortune tellers? Of course not. It is impossible to know every requirement for a complex software project before it starts. To get approval to start a budget estimate is required, as are realistic milestones, but these should not be cast in stone with a fixed-price contract.

By forcing a vendor to work to a fixed-price contract, you obscure the inevitable practice of financial and time padding added to the price to reduce vendor risk, plus huge amounts of risky assumptions, made to ensure the fixed-price contract looks viable.

Don’t worry; there is hope. Stand firm against the perceived wisdom of fixed-price bids, and design a more imaginative payment structure

Giant container ships take miles to change direction. Filling them with energetic seamen running around the deck won’t change that. When the ship runs aground, it will just cost you even more money to salvage. It’s the same for large-scale software projects. If you want to rapidly alter direction with changing requirements, then you need a nimbler craft to sail in.

The best vehicle is Agile with a time-and-materials contract. Have penalty clauses in place in case agreed-upon high-level deliverables are not met by a certain date, and bonuses if they are. The latter might go hand in hand with a reduced day rate, so there is a hard incentive to meet completion dates. You can also include some fixed-price clauses for discrete pieces of work within the project if, for example, environment builds are required, or specific documents like solution design documents or project plans are needed.

Project work can never be open-ended. There must be a target date and a target budget. That goal must be mutually and realistically set by both buyer and vendor, trusting in each other’s abilities and processes. Crucially though, you must allow for changes without requiring a return-trip to the drawing board to renegotiate contracts and deliverables every time something unexpected crops up. Stops in the project kill work momentum and increase costs; they don’t reduce them.

The Bottom Line: Relying on fixed-price contracts alone doesn’t make sense in a business environment that craves Agile Project Management – enterprise leaders and vendors alike must rethink pricing structures.

Next time you read about an IT project budget overrun, ask yourself if the project overspent, or if the negotiations resulted in a fixed-price bid with the wrong price set from the start. The reality is that if businesses want to be truly agile, then a more imaginative engagement model than fixed-price bids is required. Fixed-price contracts may appear to wrap your IT development project in strong governance, but they will inevitably lead to price overruns and fewer benefits.