Leadership

10 ways to effectively estimate and control project costs

Estimating what a project will cost is only half the battle; controlling those costs during the project and after delivery is equally critical.

Estimating what a project will cost is only half the battle; controlling those costs during the project and after delivery is equally critical.


Note: This information is based on a previously published article and is also available as a PDF download.

Building a better bottom line is just as important for an IT department as it is for the whole organization at the enterprise level. Implementing sound financial management within an IT framework is broader than simply being more efficient. Many factors are involved: an understanding of the main drivers of IT costs, aligning IT spending plans with overall business strategy, using financial resources efficiently, viewing IT expenditures as investments and having procedures to track their performance, and implementing sound processes for making IT investment decisions.

Estimating what a project will cost is only half the battle; controlling those costs during the project and after delivery is equally critical. In this article, we examine some methods to predict and manage costs, part of a sound basis for overall IT financial management.

1: Control baseline costs

Nondiscretionary money spent maintaining established IT systems is referred to as baseline costs. These are the "grin and bear it" costs, those required just to keep things going. Baseline costs constitute around 70 percent of all IT spending for the average organization, so this is a good place to start. These costs tend to creep over time due to the addition of new systems, meaning there's less money available for discretionary project work. Worse yet, this creep gives the appearance that IT costs are rising while the value derived from IT investments stays the same or actually goes down.

Fortunately, baseline costs can be easily controlled. Renegotiate vendor contracts, reexamine service levels, manage assets effectively, consolidate servers, sunset older applications, maintain a solid enterprise architecture, and practice good project and resource management. By so doing you can lower the percentage of the IT budget allocated to baseline costs and keep them in line, avoiding problems with opportunity costs. Think of IT projects as an investment portfolio; the idea is to maximize value and appreciation. Baseline costs are food, clothing, and shelter; we have to spend the money but it doesn't have to overwhelm the budget.

2: Acknowledge hidden IT spending impacts

Gartner estimates more than 10 percent of corporate technology spending occurs in business units, beyond the control of IT. Several factors contribute to increasing hidden IT spending:

  • Flat organizational models more difficult to rein in and control
  • Virtual enterprise structures ostensibly set up as nimble, agile organizational constructs but without regard for policy and procedure
  • Changing organizational authority where business unit managers are given (or take) responsibility for decentralized technology spending
  • Selective IT outsourcing, in which a business unit will independently decide it doesn't need to participate in overall enterprise architecture to fulfill its departmental mission

The impact of all this hidden technology spending can be profound and prevents IT from being able to control project costs. Architectural pollution from rogue projects can delay change, resulting in cost overruns and lost opportunities. Business unit-sponsored systems eventually become the responsibility of IT, increasing the cost of support and maintenance (there are those baseline costs again). Cultural biases in business units may conflict with overall strategic goals, increasing costs and resulting in the destabilization of information and knowledge. This is just as important for small companies as well as large; fundamental business decision-making is driven by solid information, and if we don't have it we can't do it.

3: Understand long-term application costs

As a general rule, ongoing application costs are about 40 percent to 60 percent of the original development cost for each year in an application's life cycle. Sound like a lot? These are the costs associated with application support, maintenance, operations, software licenses, infrastructure, and allocated help desk and operational staff. Controlling these ongoing costs is critical; as a component of baseline costs, they're necessary evils. Collect and maintain information about all new development work underway throughout the entire enterprise and actively participate in all projects as a value-added business partner. Communicate effectively and relentlessly; report to senior management anticipated costs both at the start of projects and at appropriate intervals thereafter. Don't forget to maintain a historical record of all costs.

4: Understand IT cost estimation truths

How good an estimator of project costs are you? I'm sorry to disappoint you, but no matter how good you think you are, you're not that good. None of us is; your crystal ball is just as cloudy as anyone else's. This is the single biggest reason IT projects have such a high failure rate. Remember: The cost of IT initiatives will typically exceed original estimates by an average of 100 percent.

Institutional knowledge is lacking as to the result of major initiatives, the advice and counsel of IT is routinely omitted or ignored, and business process change relies too heavily on IT ownership of those business processes. How often have you been called upon to estimate, if not virtually guarantee, a project cost before the scope has been fully defined?

As an IT professional, whatever your role on a project, you must provide business managers with parameters for setting funding expectations and force those business managers to explain why their assumptions are valid. If you're an IT manager, track all major development efforts throughout the enterprise and regardless of your role, participate in the creation of a knowledge base of maintenance and support costs to drive future verifiable and credible estimation. Don't underestimate the future costs of maintenance and support and whatever you do, don't make the classic cardinal error: Do not, under any circumstances, pad budgets in anticipation of an underestimation. Keep track of project costs as the project unfolds and communicate, immediately and vociferously, the instant you detect even the potential for an overrun.

5: Leverage current system investments

Applications, purchased software, networks, infrastructure, and any IT investment should all be regularly reviewed, at least on an annual basis, to ensure maximum value is being extracted and that original ROI goals are being met. Start with the original requirements and review them to ensure return on investment goals were delivered. Examine changes in the business and review new requests to determine whether they fit with the existing systems. Consider business reengineering. Review embedded processes to determine whether they're consistent with new organizational models and make changes where necessary. Review vendor and product features, making sure they still fit within the organization. Enterprise architecture is organic; it's not once and done. It changes over time. Keeping up with those changes allows for adjustments either at the periphery or by making modifications to existing components. This is an effective way to control overall costs.

6: Implement short-term cost cutting measures

Often we can control costs by putting in place tactical solutions. Short-term thinking can also be an effective tool in project cost estimation, in that it focuses us on the details. Getting from New York to Tokyo involves a fairly long flight, but we can't forget that we still have to figure out how we're going to get to the airport to begin with.

Try to postpone capital purchases as long as possible. This may not only provide time to negotiate better costs, but an idea for a less expensive solution may present itself after the project has begun. Always control project scope. Come to agreement as quickly as possible with business unit customers and sponsors as to the overall project scope and put that in writing. Have an effective change management process for the inevitable "just one more thing" discussions, which will limit or postpone until after project delivery the single biggest reason for cost overruns.

Try to control human resource spending. There are only two reasons to use external consultants--to fill a knowledge gap (we don't know how to do something) and to fill a resource gap (we have too few to complete the project on time). Negotiate the best possible rates and where possible, use fixed-price agreements rather than T&M (time and materials).

7: Implement long-term cost cutting measures

Be tactical, but don't forget to be strategic at the same time. Make sure there's an enterprise architecture; it's hard to put the puzzle together when you have no picture on the front of the box to go by. Eliminate duplicate processes and systems, eliminating unnecessary costs in the process. Reprioritize and rejustify all IT projects on a regular basis. Just because something made sense in January doesn't mean it still does in August, so why waste the budget? And outsource selectively. These are the costs that typically are the most controllable yet too often lead to the highest cost overruns.

8: Implement pricing and chargeback mechanisms

I once worked for a CIO at a Fortune 500 company who decided an internal chargeback process was needed to make business units more accountable for technology costs. He successfully implemented the new approach and was credited with saving the corporation many millions of dollars. He was also fired, because this approach is the one most fraught with political peril.

Absent a chargeback mechanism, business units tend to look upon IT as a giant free toystore. Put one in place and those same business units feel free to go to the outside to get more competitive technology pricing, and IT loses control and becomes marginalized.

If your company is going to consider this, there are ways to achieve both goals: making the business units accountable and maintaining central technology architectural control. Internal IT must be competitlve with external service providers. Periodic benchmarking exercises are key. Don't underestimate the substantial resources needed to effectively administer chargeback mechanisms to ensure that business units have all the information they need and no one feels at a disadvantage. IT must have a clear understanding of all costs and manage the demand appropriately. Use client satisfaction surveys and service level agreements (a good idea no matter what the circumstances) and always show a balance between costs and benefits.

9: Use governance to drive IT investment decisions

Too many organizations fly blind, with little synergy between IT and the business. In most organizations, IT is a discretionary expense center; there's a fundamental framework (baseline costs again) but most, if not all, of what's required beyond that isn't necessarily mission critical.

Enlightened organizations understand that IT is a value-added strategic business partner, and a successful collaboration between IT and the business drives significantly increased stakeholder value. Establish, or if one exists become a participant of, a strategy council to examine enterprise-level issues of strategy, politics, priorities, and funding. Set up a business council to define priorities, oversee projects, and measure (and communicate) project success across business units. This group must, of course, have the courage to cancel projects when that becomes necessary; not everything that starts must finish. Put together a technical council to develop guidelines and principles for technology standards and practices. These are three very different organizational constructs, and while there may be some overlap in terms of participation, the mission of each is mutually exclusive.

10: Quantify the value/benefit proposition for IT investments

Why do we do what we do? That's not an existential or rhetorical question. IT exists to provide value, to participate in the achievement of organizational strategic goals. How can we prove we've done so? Just because we've built a thing, that doesn't mean much. Does the thing work? Does the thing provide value? Is that value measurable and consistent with the corporate mission?

Some quantifiable benefits of IT work can be improved operating efficiencies, enhanced personal productivity, enhanced decision quality, and/or enabling or supporting organizational strategic initiatives. What's most critical is to ensure the credibility of any measurements used to justify IT investments and provide after-the-fact valuations. You may be working on a project that will reduce a process from five person-days' worth of work to two. Does that mean three people are going to be fired, with the resulting compensation cost saving attributable to your project? Probably not. Those folks will most likely be reassigned, so don't take credit for expense reductions that aren't going to happen.


Check out 10 Things... the newsletter

Get the key facts on a wide range of technologies, techniques, strategies, and skills with the help of the concise need-to-know lists featured in TechRepublic's 10 Things newsletter, delivered every Friday. Automatically sign up today.

3 comments
jtheires
jtheires

Thanks for posting this article, but the costs mentioned in item #3 are not true project costs. According to the PMI (and other authorities) a project has a finite duration. This means that projects end. Ongoing, long-term application costs have no pre-defined end, and therefore, are not project costs. That said, ongoing costs should still be managed and controlled. However, these costs are typically the responsibility of an operational manager, not a project manager. Since the PM profession is quite mature, we all need to be a little more precise with our guidance to those who work in it.

Tony Hopkinson
Tony Hopkinson

What you are saying there is if you produce a turd at the right time, you are a success. Dealing with the mess is someone else's responsibility. Given the number of occasions this happens, I always suspected it was deliberate......

yeoman
yeoman

Absolutely agree. When we prepare a Business Case to justify putting in a new system or to enhance one we do need to include the operational costs, here called "long-term application costs". In fact, a lot of what Jeff Relkin is talking about is building the business case. Before we embark on any project we (with the business owner) need to identify what we are trying to achieve and justify why this project is needed (#9 and #10 in Jeff's list). The justification will include the cost of doing the work (#4) and on-going costs, sometimes called "total cost of ownership" (#1, 2, 3, 8). These costs may be reduced by various measures (#5, 6, 7). A lot has been written on estimating work effort. Jeff has identified a very important practice: keep track of what you have done. This provides historical data which can be used as a starting point for future estimates, which enables us to become better at estimating similar work in the future. Use hindsight!

Editor's Picks