We still hear some (potential) customers expressing a preference for a fixed-price implementation. In this blog we will explain why a fixed-price proposal is particularly bad news and how to handle that million-dollar question: How much will this all cost?
Jump right to the sections:- Why Fixed Price implementations are bad news
- The general reasons
- How an Agile solution trumps Fixed Price
- The cost estimation quagmire
- Answering the million-dollar question: What will it cost?
- The last piece of the puzzle
- Explaining the cone of uncertainty
Want to get an accurate estimate of your project costs?
Want to read this offline?
Why people ask for fixed-price implementations
By reading this article it is likely that you have already been involved in EPM implementations, whether as a designer or as an end-user.
Did you ever hear these three points?
1. A fixed-price implementation reduces risk.
2. Consulting parties who prefer a fixed price contract show confidence and prove they are more experienced
3. Governance policies force key stakeholders into requesting only fixed price implementations.
Read on to find out why 1 and 2 are wrong and 3 will get you in trouble
Why fixed-price is bad news for customers: The general reasons
The implementation of an EPM tool is no different from any other project when it comes to downsides of fixed-price contracts:
- Consultants are forced to severely limit scope of work to reduce risk on their side
- No flexibility to change requirements as the project progresses
- Consultants are forced to spend valuable money going into tiny details of the project to get an accurate price, which is time that everybody would rather they spend on designing and building your new tools.
- Some consultants may react by adding a fixed contingency budget for unknown developments in the project, so you end up paying for work that you never needed in the first place.
- With long lists of assumptions that lock-down the requirements from day 1, the customer will be stung with high fees when the scope changes.
Why fixed-price is bad news for customers: The next generation EPM tool reason
Picture the following scenario
A key stakeholder learns some valuable capabilities of the new EPM tool during a training course, near the start of the project, but after the contracts have been signed. The person comes back from the training saying “I wish I put that into the original scope!”.
Once the other stakeholders find out about the new feature and its value, they instantly want it.
As consultants, we want to facilitate this, not because it increases the consulting budget, but because it ensures customers get the best value out of the tool. The last thing you want to say is, “Sorry this is fixed price, so fixed scope” and thus no instant added value for you.
The crystal ball
During the early stages of design & implementation, with a new next generation EPM tool, customers usually become aware of more value-add solutions that should have been on their wish-list, but were not included in the original scope & requirements, because the original business case was based on knowledge of old & outdated EPM tools.
With a fixed price, it will be very difficult or even impossible to adjust the project scope to realize these new solutions with the costly consequences ranging from implementation of a sub-par solution, vendor re-negotiations and /or future application re-design.”
How an Agile solution trumps Fixed Price
There is a lot of material in books, seminars and online about the Agile approach to project management, and we do not intend to go into such details in this article.
Most people reading this will probably be aware that the Agile approach means breaking down the requirements into smaller deliverables that can be implemented and tested in much shorter timespans, usually in weeks rather than months.
The point here is that when you are building a business case for a new EPM tool, you want to steer expectations towards a budget, not an estimate.
We hear you think: but isn’t this the same thing?
How can you provide a budget if you can’t provide a work estimate for everything in the requirements / business case. Hold your horses! We will explain.
The cost estimation quagmire
Tell me! How much will it cost?
It all comes from one source: An executive says “how much is it going to cost?” which traditionally drives everyone below them in the organization to shop for (a) lowest estimates and (b) preferably fixed-price.
The external consulting parties bidding for the business will go away for a few days, come back with some more questions, and then the following week come back with an estimate, a proposed project plan, and a list of assumptions.
It can be extremely difficult for a customer to understand the implications when they apply to a new EPM system which they know virtually nothing about.”
The issue with assumptions and estimated cost
Probing these estimates takes a lot of time, because you have to really analyze the assumptions given from the consulting companies, and really understand all the implications of those assumptions.
From our experience this analysis by customers doesn’t happen, and most of the time are pointed to an appendix in the Statement of Work stating a long list of assumptions that might be things like:
- “X is not in-scope”
- “You will have X internal FTEs available throughout the project”
- “You will have a maximum of 10 reports”
Miscommunication in this area quickly turns into an arm-wrestling match, and really does nobody any favors and in the end it doesn’t matter if the consulting company delivers everything they said in the statement of work in accordance with the list of assumptions.
So, what’s the point?
If a misunderstanding of the assumptions and the related impact arises, then it doesn’t matter how accurate the consultant’s estimate was because this will always influence the cost indication.
Estimates can be too precise
Ask yourself:
Why go into small details in every part of a project, if you know that those parts are not high-priority parts to be delivered first?
Do you need this level of detail?
Imaging breaking down a 100K business case into several small chunks lasting only a day or two. That’s a lot of work because you’re filling up your project plan with micro tasks which may give a lot of justification for your cost, but at the same time you know that these tasks will hardly ever happen on those dates, or during the project the requirements will change anyway.
Starting to question what’s the point in this level of detail?
Now try doing this for a €200k or €500K project, and it becomes ridiculous because you know you cannot get the estimates on such small details before the start of a project.
Go for a Budget rather than an estimate!
The discussion about the Agile approach above still doesn’t really answer the original question “how much is it going to cost?”.
Read on to find out.
Step 1 of how to answer the million-dollar question
Budget top-down
Only go into the details where you need it to make a decision. When building a new EPM implementation you define your high-level functionality which could be something like this:
Does this answer: how much is this all going to cost?
No, but once you get into the next level of details you should be able to put a range on the cost, for each task.
Afterwards you may still have a wide range of estimates, say €50k - €80k
And now you can say
If the budget is €40k, then we have all the information needed. We can’t afford it.
- If the budget is €80k, then we definitely have all the information needed, we can afford it, so there’s no point wasting time in the details.
- If the budget is €70k then we don’t have enough information, so the go into details on the tasks that still have large variances in estimates, and ask more questions in those areas.
Step 2: Prioritizing and raising confidence Levels
By this stage you should have worked with your consultancy partner to get a priority of all the tasks, so you can list them in order of priority
For example:
At this point, it will have taken only a few hours to come up with this, instead of several days to come up with a detailed plan & estimate for every micro-task in every deliverable.
Step 3: adding likelihood of finishing within budget
We still can’t answer the question “how much will it cost” but we are getting there!
Your new overview will look something like this:
Dropping off on the percentages
During the implementation, the re-budgeting exercise can be done again in a few hours, as requirements change. With an Agile approach, the project is made up of achievable sprints.
You make progress in time-limited sprints that demonstrate capability and build trust.
These days we nearly always propose projects based on the co-build principle, so internal resources are co-responsible for building the components with (us) the consultancy partner.
As they get more experienced in the project, your own staff learn to become more and more self-sufficient, and less reliant on external consultants.
So this ‘dropping off’ on the percentages in the table above is compensated by the own-staff gaining confidence with building using the new tools, and being able to complete the tasks as a co-build.
Getting the answer to the million-dollar question
Estimating everything in detail before the start, before you know the new EPM tool, is not worth the effort so early on. Push for budgeting instead.
If the requirements change, no problem, we haven’t wasted valuable time and research effort on looking into small details.
Ultimately it is your own project sponsor to answer the cost question.
The last piece of the puzzle: The cone of uncertainty
Uncertainty leads to variability
During the early stage of projects (i.e. requirements gathering), details of specific requirements are unclear, and as mentioned in the previous section the work estimates can vary enormously because of the build-up of many small details.
This uncertainty leads to variability in project estimates.
It is only as the project progresses, that more clarity is known about the scope and work effort.
The last piece of the puzzle The cone of uncertainty & estimates
The worst time for estimates Estimates
Estimates created at the start of a project, or before signing contracts, will always be subjected to a list of assumptions that may or may not be valid. As mentioned earlier, you cannot be expected to fully understand the implications of all the assumptions, since they refer to a new EPM tool with which they are not yet familiar. This is the widest end of the cone of uncertainty and the worst time to make estimates.
When combining the Agile solution and the benefits of arriving at a budget, with what confidence levels do you still think Fixed price is your best option?
Full control without a fixed price
The original ideology of asking total estimates was based on assumptions where the customer outsources all the work to the consultants, with internal staff taking no interest in the build phase, and the users just being told to use the new tool when it’s ready.
Instead of comparing total cost estimates from each of the consulting parties, compare what work can be done within the budget. That ensures you prioritize the work, and actively participate in the co-build.
Once you understand that the Agile approach, combined with a budget-based project (rather than total guesstimate for everything up-front), is better than working the old way, you realize that you have complete control over priorities, and much more likely to continue to collaborate, and achieve the best solution completed within the anticipated budget.
Remember this!
1. Fixed price estimates normally don’t serve your best interests
2. Don’t underestimate the cone of uncertainty
3. The agile project approach is the best method to ensure a successful EPM platform which can be used and maintained by your own resources for many years
4. You are in control when you establish a budget based on various high-level estimates of fundamental requirements and deep dive into specific details based on priority.
The conditions for a fixed price project
From time to time we do offer fixed price but only if the conditions are right for both parties.
We recently built additional functionality at an existing customer who were already familiar with their EPM tools. In this case, and other examples before:
a) We already had the relationship built on trust and known expectations
b) The new functionality was modelled (e.g. using Excel prototypes)
c) We were confident that the scope would not change during the implementation
From our view:
A fixed price should only be agreed to when a mutual trust has been established, there are zero to a very few assumptions and it is certain that the scope doesn’t change.
Want to have a clear view on what your EPM project will cost?
One of the reasons why companies like Schiphol, TMF Group and Takeaway.com work with us is because of our approach to project costs. They are the most accurate in our field. Giving you a clear picture of what this will all cost with no suprises at the end.
No assumptions which lead to additional costs
Always within budget
Always on time
With you being in full control