Unnoticed differences in project requirements or unquestioned assumptions can lead to project estimating mistakes. Fortunately, these mistakes are avoidable if we don’t take any component of a project cost estimate for granted.
Three Common Ways We Miss on Project Cost Estimates
Looking back through some of my projects, I see 3 main ways that you end up with incorrect cost estimates:
- Not questioning bundled costs.
- Using historical numbers without vetting their current accuracy.
- Not questioning the cost of legacy resources vs new tools.
These are not the only ways to throw off project cost estimating, but these are common ones for projects and organizations of all sizes.
Using Comcast-Style Service Bundling for Project Costs
Web development firms, marketing companies, ad agencies and other vendors also tend to bundle services. Sometimes this is a good thing for efficiency and/or costs. For example, you can save time on a web project or marketing campaign if your developers will also slice your PSDs; or your ad agency can do purchasing across media types (e.g TV, Radio, Print). But sometimes the bundled services are not needed or you have an alternate resource that can do them at a lower rate. You need to know that these unnecessary bundled services are there, and make it clear that you don’t need them to avoid the cost.
How to un-Bundle Project Cost Estimates
The best way to avoid paying for unneeded services is to be clear about your requirements and make sure vendors clarify their offerings. You’ll want to review SOWs and contracts for any line items that don’t seem to fit. If possible, you’ll also want to get a look at the hour estimates for different phases.
It’s easy to assume that everyone is on the same page after going through an RFP or scoping talks, but you can’t get complacent. Don’t shift to looking only at the high-level breakdown of work.
You want to look at the detailed estimates both before project/phase start, during, and at closing. A good view to use is the Work Breakdown Structure (WBS) which is a deliverable-centric view of the project with cost/time baselines. If you’re managing the project, then you should have one, and you can also ask your vendors for them.
The example WBS to the right is for the installation of a new CMS and migrating of content to it. There are 2 areas here where you could question the vendor about the hours and cost. The first is the yellow section for backups and exports. Do you need a vendor to do this or can your web manager do it and then deliver the files? You might save $1,000 by making this simple change.
The other area to look at is the red highlighted piece “Configure CMS”. The other WBS items are tasks while this is more of a category of work. You’d want to go back to your vendor and ask them to breakdown what this entails.
Line-item reviews of project documents can be tedious, but they are necessary. Remember that any money you save here could make the difference in a later phase.
Using Past Project Costs as Prescriptons
You might look at past projects and assume that the costs will be the same for your new initiative (e.g. web development will take 160 person hours at $95/hr). This is a great way to get started because it’s leveraging real data, but you should remember that rates increase, resources exit and requirements shift.
The tricky thing with adjusting these costs is understanding the context of the original numbers. For example, you might have received a discount from a consulting firm if you agreed to do a case study. But that deal isn’t on the table 2 years later when you come back to them for more work.
You also have to think about human resource costs. For example, a front-end developer might cost 20% more today than they did in 2010. You’ll be paying more now, even if you are talking about very similar work.
How to Revise Historical Project Cost Estimates
There are a few ways to bring historical numbers up to date without going to vendors before you’re ready.
- Search glassdoor.com for current salary trends on the role you’re looking to fill. It will give you salaries based on your location and also show you what salaries apply to different job title variations.
- Ask team members how they’d get a certain task done or deliverable created: they’ll often be able to point you to someone in their networks or tell you about a tool that will do the job.
- Review the artifacts from the previous project. Can anything be reused? Things like handouts, banners, and email templates might be viable with some edits; and you might be able to get these done in-house. Also, don’t be afraid to chop and remix old documents like whitepapers to make something new.
- Apply a multiplier to hourly rates. Add 15-20% to what you paid last time. It may end up being too high an increase, but it’s better to overestimate and not need it than to have sticker shock (or funding shortages) later.
You’ll eventually have to get fresh estimates, but you can get ballpark figures from these techniques. Just remember that different skills see different rates of wage change. Any programming role is going to cost more now than a few years ago. In contrast, you can find writers and campaign support cheaper now through sites like Fiverr or Freelancer.
Using the Same Tools or Suppliers You Used Before
The cool (and frustrating) thing about technology is that there is always someone working on a faster, better, cheaper way of doing things. With digital projects, you may be able to find an opensource solution for something that required a 50K investment 5 years ago. You might also find that tools you currently use have added functionality that you used to have to get elsewhere.
Legacy systems are a cross we all have to bear. Years of adapting to business needs and connecting different systems means that we can’t move on without comprehensive, long-term change management plans. Changing these systems are often projects in their own right.
There are sound financial reasons to sign a longer-term contract, but you always risk getting stuck with a higher price tag if new competitors enter the market. Depending on specialization, you might be stuck with a specific vendor.
For either type of lock-in, the key thing is to get out ahead of your needs. You want to round up alternatives to the current service set and be able to do a point-by-point comparison on both features and costs.
How to Find Cost Savings with Current Resources
If you know that you can’t change tools or contractors, then you need to look at ways to squeeze more value out of them for your project.
Bring your project needs to current vendors, agencies and consultants with examples of alternatives, and ask them to explain what they can do for you. Phrase everything as if you’re trying to leverage existing commitments, not generate new business for them.
If you can get them to give you some extra services for free or at a reduced cost, then you will save money over setting up a new contract or add-on. Depending on your project, you might also be able to negotiate a deal for agreeing to beta test some new functionality or serve as a case study for their methodology.
Also, don’t be forget to ask for referrals for other requirements. They may have relationships you can leverage to get better deals for complimentary services you’re going to need. You may not save on them, but you might save elsewhere due to the referral.
How to Figure Out if Change is Worth It
If you decide that you want to change systems or contractors, then you need to add the cost of change for your organization to your estimates. This cost can include penalties for ending a contract, new licenses, onboarding time, the need for re-training, new hardware, bringing in a specialist, etc. If you don’t include these costs, then you will find that your estimates come up short.
You’ll often find that including the cost of change means you’re paying more in the short-term. For systems, you should think in terms of payback periods. If the period is not too long and the opportunity cost is high enough, then it will make sense to switch.
For smaller projects, this either isn’t something you get to discuss or is so low cost that it doesn’t matter, but you still want to do the math.
Be Responsible but Be Realistic
Both smaller organizations and smaller departments in larger orgs regularly spend more than they need to on technology projects because they don’t have the resources to thoroughly vet every cost. Some of things can’t be properly estimated without a lot of help due to complexity, time constraints or lack of precedent. Things can also get tricky if you’re working on large scale projects across departments with their own value calculations and priorities.
You want to be as granular and conscientious as possible with your estimating. But we have to be realistic about what we can get done. Focus on dissecting the big cost centers and then look at smaller items. Also, trust to organizational memory when you can: if you have a team member that has done several similar projects, then you can ask them to apply their experience to the estimating. And you can do something similar with your accounting department: ask them to give you the final costs for recent efforts.
The point is to find savings or better allocations with the time and skills you have. I hope this post helps you save some money or spend it better.