Lessons learned or how to improve your inner manager
• 11 birželio, 2020
Arturas Rimkus • 4 gegužės, 2020 • Case study
I don’t like fixed-price contracts, or at least not in my industry – software design and development. It’s not that I don’t like constraints and deadlines – on the contrary, I think they help one focus and sometimes accomplish more than within complete freedom of action. It is, however, artificial constraints that urge me to consider alternatives.
The most prominent alternative to fixed price is the Time & Material, or simply T&M, type of contract. I will assume that the differences between the two are obvious and won’t bore you with explanations on what they are. However, I will put them head to head in order to show why my feeling, which has gradually turned into a strong opinion through experience and analysis, indicates the fixed price model as the inferior one.
A couple of considerations before we get into it:
With this in mind, here’s why I believe clients would be much better off with T&M contracts versus fixed price.
To begin, let’s look at the main reasons behind choosing a fixed price contract over a T&M. The very word ‘fixed’ implies that there is a better (perceived) clarity around the object of the contract, which in turn provides more reliable guarantees relating to:
Let’s look at each one separately.
It will help you manage costs. However, it won’t let you do it better than a T&M contract would, as it’s just as easy, and just as common, to set up a budget for the latter.
Even if we assume that both can equally well control maximum spend, I would argue that business value received for the budget would be lower in a fixed price engagement, and here’s why:
Change management is an important consideration here. Since a fixed price contract shifts all risk to the vendor, after contingency premium, change management is the vendor’s primary tool for mitigating that risk. Since the purpose of change management is to identify any deviation from baseline requirements, price it and charge for it as additional work, this more often than not results in the final cost of delivery ending up higher than that in the original contract, thus hindering the effort to control total spend.
Even though the name refers to a fixed price or fixed fee, what sets it apart from a T&M contract is an intended fixed scope. However, I think it’s needless to say that in most projects, especially in software projects, the definition of exhaustively detailed requirements prior to commencement of delivery is very impractical – not impossible, but impractical. What makes it so:
Say, you do decide to define the full requirements upfront. This requires a very concentrated effort and exceptional analytical skills. However, even if it is done, the following financial implications have to be considered:
Therefore, a fixed price contract type is only applicable in an impractical situation, to begin with.
This is true. If a vendor is falling behind a delivery schedule, the team can be ramped up, or development speed increased in other ways, if necessary, to meet the delivery deadlines. However, the same can be achieved with a T&M contract when working towards a milestone in a release or delivery plan. After all, a T&M contract often only defines the daily rate and total budget with sufficient flexibility in budget burn rate while working towards delivery goals.
Furthermore, the fixed price approach implies that to deliver a fixed scope in a fixed amount of time; one needs to indicate, evaluate and contain any project-external influences and dependencies on any third party or client’s own internal resources that can impede a fluent delivery of the final solution – an extremely difficult task that often ends up with inflated SLAs and other commitments that are designed to act as insurance against non-delivery as opposed to reasonable coordination of efforts. With a ticking T&M meter, on the other hand, it is in the client’s best interest – mind you, both for vendor’s (smooth, uninterrupted delivery) and client’s (efficient spending, fast delivery) sake – to ensure actions of different parties are orchestrated within the reasonable planning horizon to minimise/eliminate any downtime of project resources.
OK, so if we take away all the ‘comforts’ of the ‘clarity’ of the fixed-price contract, and move all the risk back to the client, how can I possibly say that a client would be much better off with a T&M contract? Because, believe it or not, this is precisely what I am saying.
Well, the biggest issue, which I have witnessed all too often, is to do with the mentality behind a fixed price approach. Once a fixed price project is signed, and in the drawer, the client goes into a state of mind which is something like ‘Ah… I can finally kick back, relax and just wait until my product is delivered to me’. And while this might be true for when you order a pizza, this is never the case when you order custom-made software.
What is the most critical input into software delivery? It’s requirements. There’s a reason why Product Owner is such an essential role in a project. And while development, QA, design and a number of other skill-sets are extremely important as well, it is the business value delivered through well-conceived and prioritised requirements that determines success and failure of a project to the business.
And get this – product/requirements’ management is always (or should always be) the function of the client. And while T&M approach leaves all the risk with the client, it is an illusion that this risk can be outsourced or sold at a premium (such as in fixed-price contracts). The only way to deal with this risk is to manage it, and the best and only tool to do that is the proper requirements’ management.
I have already made a point that it makes little sense to prepare upfront full-detail requirements. Still, more often than not one would want to do some upfront requirements definition/design – only enough to understand the scope of the project, inform architectural considerations as well as allow for very high-level sizing and estimation – never a commitment. Instead, as requirements are being produced and refined, they are also prioritised to make sure that more important functionality will be implemented before the more trivial ones.
So, where the fixed-price approach is trying to box requirements with time and cost constraints, T&M merely uses either or both of the limitations as a line which can easily be crossed (through trade-offs) while performing the task of continuous (re)prioritisation to deliver highest business value within the constraint.
I believe that what a T&M contract does is create a straightforward thing, and that is a healthy collaborative environment that is critical to any project’s success. And it does so by correctly defining the two key ingredients of a good project:
This article is, without a doubt, very one-sided in favour of T&M contracts. And for several good reasons which, if I did a good or at least a decent job, are clear and indisputable. However, it would be wrong to say that there is no place for fixed-price contracts – there certainly is.
What kind of project could qualify for a fixed price? A small one. How small is small enough? I believe the best way to gauge that is to see what project management approach you would feel more comfortable applying:
In any case, when you think about what services we usually buy for a fixed price, it’s often something relatively simple, something repetitive – a shoe sole to be repaired, a haircut, a wedding photographer hire even. However, you rarely expect a price upfront for fixing a car after an accident, or for legal services to draw up a proprietary contract without a raft of ‘if ‘clauses. Less so should we expect to give a fixed price for building software, which is neither repetitive nor straightforward? An agile approach to software delivery was invented for this exact reason that it is so difficult (virtually impossible) to plan out software delivery from A to Z. If you can’t plan it, you can’t reliably estimate and cost it.
• 11 birželio, 2020
• 7 lapkričio, 2019
• 9 spalio, 2019