The software engineering community has spawned many different methods for estimating levels of effort for implementing projects. You could debate the validity or accuracy of the projections those methods yield, but the fact remains that they're widely employed.

As Irina pointed out yesterday, there's the upfront fee you'll pay for licensing any packaged technology, which can range from zero to millions.

Beyond that, for most customers, a content management implementation represents a software project -- inasmuch as someone will be customizing, integrating, and perhaps extending the solution -- and thus demands some way of estimating your effort (and hence costs). However, in my experience, established methods such as COCOMO and Function Point Analysis don't fare well for such projects.

There are several reasons for this:

• A content management project is usually not a pure development project where you can capture metrics such as lines of code accurately. Instead, these projects usually entail a combination of package implementation and bespoke development. So you can't apply rules of thumb, such "n KLOC (kilo-lines of code) will take m days to code"
• Most of these methods give you a raw value. You then adjust that based on historical industry data and your own previous experience. There are benchmarks (such as this one that tell you how much should you estimate for a function point based on technology or project type. While it is easy to get such benchmarks for say C++ or J2EE implementation it's not trivial to get such numbers for, say, Documentum (or TeamSite or whatever).

So while such methods give you a scientific basis to convince your management or your client about the estimation accuracy, in the end they could be as inaccurate as a random guess.

I believe estimation is more art than science, and no amount of standardization can replace the gut feel of an experienced hand. So if you want accurate estimates upfront, make sure you have people with hands-on technology experience in that particular toll on the team at the beginning. Only an experienced person can say with confidence that a workflow in your favorite product will actually take 5 days, and not just a few minutes as claimed by the vendor.

Finally, remember that overruns are a reality, and so budget appropriately. Just make sure you capture the variance (and reasons) between your initial estimates and the actual effort it took. This will allow you to create your own benchmarks for future use. When used in conjunction with the gut feel of an experience specialist, you'll get the best results.