How to Plan a CMS Project - Estimation

At this point, we have an idea of what the client wants, what really matters, and what we are using to build the solution, i.e. eZ publish. What we don't know is how we are going to implement the solution within the eZ publish framework. But that won't stop the client from asking how much it is going to cost (in the case of internal projects, the question is more likely to be how long). The reality is we can only make a guess of how much it will cost, we can only make an estimate. When it comes to estimations, we need to understand the language we are using and the games people play in coming up with estimates.

Reality Check

Estimates are often wrong.

The accuracy of a particular estimate will depend on the experience of the team, the client, and the complexity of the task. A task will take as long as it takes, regardless of what estimate is given. We can't accurately state how long something will take unless we have done it before, under the same conditions.The bottom line is we can't accurately estimate the project until we know exactly how we intend to implement it.

Estimation Errors

Barry Boehm did a study in 1999 looking at the range of estimation errors during a project lifecycle.


Margin of Error

Project Start

+ / - 400%

Requirements Gathering

+ / - 200%

Requirements Analysis

+ / - 150%


+ / - 50%

In the context of a CMS project, the planning workshop can be considered requirements analysis. What this means is that at the end of the planning workshop, any estimate you provide your client can be up to 150% more than the true cost. If you try to provide an estimate before you have requirements, you could be up to 200% out. If you have an initial meeting and the client asks at the end of the meeting, how much (which happens A LOT), you could be up to 4 times out. For high risk projects with high complexity, estimation errors can be 5 times out (Rand Corporation, Charles Perrow [1984]).

Hopefully, this will scare the pants off you every time you think about doing an estimate and you'll think long and hard about any estimate that you do provide. Of course, ideally we only provide an estimate after the specification phase but sometimes you have to give an indication of price to even get to that stage. That's a part of doing business; what you need to be aware of are the risks involved so that you can avoid the common mistakes in estimation.

Usual Situation

What usually happens is we don't have enough information when the client asks us for a price, but because we are keen to please, we take a guess at what we think it will cost and the project starts. At some point, the reality of what we are doing is established, as well as how long it will take and what it will cost. Then, we have to somehow convince the client to come up with more money. There are three outcomes, the client pays the extra money, the project is cancelled or you are forced to deliver for the initial estimate given. None of these options are particularly pleasant.

So why are our estimates so bad? The short answer is because we provide estimates when we don't have enough information and we don't ask the right questions. There are also other reasons why our estimates are wrong. It depends who you ask and what their motivation is.

The Developer's Estimate

When you are asking a developer for an estimate, what you are saying is:

" Based on your experience and understanding of the project, and based on the information I've given you, how long will it take?"

Developers are mostly honest but optimistic. They will do their best to please and provide a best-case scenario. On the other hand, some have been burnt doing this and go the other way providing a worst-case scenario to protect themselves. Either way, the quality of the estimate will be based on the quality of the information they have been given. But rarely will you get malicious or wrong estimates from developers.

The Project Manager's Estimate

Project Managers as a whole are more aware of the blowouts that occur during projects and will take a more conservative approach. By default, I will get my developer to provide me an estimate of their component that I will then build into the overall estimate. As a rule of thumb, I always add a percentage to any estimate given to me to allow for some error. The size of the percentage will vary based on the experience of the developer and the complexity of the task. E.g., if a developer continually gives me best-case scenarios, I'll protect myself by adding 40% to the estimate to allow for that. On the other hand, with a more conservative developer who I have worked with before and can trust, I don't have to worry about adding additional margin.

Low Bid

The low bid is a dangerous but sometimes necessary approach. It's about sales, not reality. If you go in with what you think the project will really cost, chances are you may not win the project. Alternatively, if you go in with a low bid, i.e. the minimum cost for the features and leaving out elements such as content population and training, you stand a better chance of getting the project. However, that doesn't mean the price quoted is the final cost. You'll have to manage the budget issue at some point, through scope creep, variations, whatever term you like to get the budget to equal the true cost. This is a somewhat underhanded way to get there but sometimes it's the only pragmatic way. Once the project starts, you stand a better chance of getting more money than you do upfront. People don't like to cancel projects and you'll have more leverage. Ethically, it's questionable, but it can work.

The Sales Manager's Estimate

When sales people are involved, the only thing you can be sure of is they are more concerned about getting the sale than making sure the estimate is accurate. Some sales people will promise the world and let the developers worry about how to deliver for the price given. It's a recipe for disaster and puts the project team under a lot of pressure. There is good reason to be wary of sales people; however, without someone to make the sale, we wouldn't have any projects to work on, so they have a role to play.

Management/Client Directive

Basically, this is when the client says, I want it for $30,000, or for internal projects, management states, it's to be delivered by 30th Oct. Either way, the terms of the job have been set for you. Your choices are:

  1. Accept—start the project, get to a point when it's clear that it can't be done for the set time/cost and try to negotiate for more time/money.

  2. Reject—say it can't be done, then risk losing your job or the project.

Neither outcome is particularly pleasant. Although harder, rejecting the directive is actually the better outcome, even if it means losing the project or your job. By losing the project, you can take the time to find a project that will be profitable. By losing your job, hopefully you can find one where you get treated better. If these outcomes aren't realistic, then at least you know what you are facing and can work on ways to deal with it.

Common Language

What is handy is to have a common language when it comes to estimations. There are three types of pricing.


A guess is an uninformed predication; that's when you ask your developer how long it will take to integrate a CMS with an external database and they come back with the helpful statement, as long as a piece of string. Fortunately, we all know the length of a piece of string is twice as long as the distance from one end to the middle. Not very useful. A guess is simply that, a guess that we can place no guarantees on; guesses are to be avoided like the plague. Fortunately, my lead developer Bruce has an inbuilt guess avoidance feature. If I ask him to make a guess, his answer is more than 3 hours, less than 3 months. And he's usually right. The short answer is, don't make guesses!


An estimate is an informed/expert opinion based on an informal and incomplete documentation and process. Basically, we have discussed what it is that we intend to implement, done some basic documentation, and a bit of research and have a reasonable idea of what we are doing but there is still a lot more work to be done to provide a true estimate. Estimtes are what we provide once we've got the requirements and have completed the planning workshop. We have a pretty good idea but the devil is in the details and that's why it's only a guesstimate. If you provide an estimate to a client, be careful to explain that it WILL change and has a reasonable margin of error. You may choose to increase the estimate to protect yourself but it may also backfire as you may lose the job if you are too conservative (trust me, I've been there!).

Fixed Price Quote

A fixed price quote is what we are after. It's an informed opinion based on formal, agreed documentation. In our case, it's the specification. Until you have a complete specification that the client has signed off, you are dealing with estimates. Based on a specification you can give a fixed price quote estimate and be confident that you can deliver for that price. Note: Even then, there can be room for error as Boehm's study on estimation errors has indicated. However, given we are working with an established framework, the margin of error is reduced and an variances will be caused by the project team's experience level and the quality of the content/data provided by the client.

The Ideal Situation

Don't give a fixed price quote unless you have enough information or call it an estimate so the client knows it's not final. Otherwise, get time to do enough investigation to get the information you need—a simple solution but not always easy to pull off!