September 20, 2016
The idea that you can derive the implementation costs of a complex software system based on the licensing fees of the software is something that we at Valtech commonly encounter. There are some reasons why this practice persists but perhaps most importantly is the need to establish a total budget.
Without that total budget there is no way to assess the return on the investment and gain procurement approval. This is due in large part for the need to derive budget to gain approval and is perpetuated by many vendors to the detriments of their customers. Unfortunately, this approach is completely broken. In this post I explore why and suggest some different approaches.
The reality of complex projects
No two projects are alike. The idea that we can take a licensing cost and apply some multiplier means that every customer who buys a CMS at the same licensing level should have the same implementation costs. I think we can all agree that does not hold water. Customer A buys the CMS for X and will deploy four sites with distinct branding in a staged rollout over three years. Customer B also buys the CMS for X and will deploy a single site in a single full reveal launch. If Customer A can do all of that work for the same cost as Customer B I would love to know how.
Based on the goals of your implementation you need to carefully assess scope, responsibilities (your team, vs an outsourced vendor team), and rollout approach. If a project is anything more than the most trivial scope, most organizations will require a short pilot or discovery process to narrow down a ranged estimate. If you are working with an external vendor their experience with past projects of a similar nature can be used as guide rails.
Breaking things down
To get a real handle on possible costs you will need to break them down. The challenge is that many of the breakdowns that are published in RFPs are structured in a way – in my opinion – that obfuscates costs. The common set of categories I see go something like:
- Install CMS
- Configure CMS
- Annual support
- Data / content migration
- Hosting
- Training
Some of these I’m OK with provided the assumptions that constrain the numbers are very clear (hosting), but the idea that even something as deceptively simple as training can be boiled down like this is dangerous. After all you are not asking for someone to deliver training, rather you want your users to be able to effectively take advantage of the new solution.
Suggestions
To get to a realistic estimate with an experienced implementation team/vendor, there are some basic questions you need to have answered. You will note that I have excluded traditional scope items – they just vary too much from project to project.
1. Website user experience
(a) How many personas do you believe you need to represent your clients/users?
(b) Is new branding required, or will the website(s) be an interpretation of an existing brand?
2. What technical environments do you need to support (development, qa, uat, production)?
3. What are the requirements for disaster recovery, both return to operations (RTO) and recovery point (RPO)?
4. Of the above environments, what is the targeted SLA? Is there a preference on hosting arrangements or location? For example, non-production in house and production and disaster recovery in the cloud?
5. What is your desired approach to usability? Wireframe creation, prototype testing, formal usability testing?
6. Are there regulations you must be compliant with?
7. Change management. How large is this change for the organization? If significant, who is leading the change, who is running the communications plan?
8. Does your project team have experience with projects of this nature?
It has been my experience that the answers to these questions can influence the total cost of a project as much (or more than) the actual definitive scope items. At the end of all of this a project is really about getting a bunch of people with disparate skills to work together to a common end. Experience, process, and procedures can help guide us but ultimately it is the “soft” aspects of a project that are most important.
