Develop a reliable estimate during an elevator ride? Yes you can.

Colleagues conversing in an elevator

“Elevator Speeches” are an important tool in management. By chance, you find yourself in an elevator with a senior decision maker for 30 seconds. Can you do something useful with that time? You should have an “elevator speech” ready, or be capable of generating one instantly, for several topics, such as:

  • Who are you?
  • What do you do?
  • What are you working on?
  • How’s it going?
  • Anything you’d like me to know?
  • Do you think we could problem-or-concept-you’ve-never-heard-of-before-this-moment? What would it take?

This post talks about an important “elevator response” skill – quickly estimating costs by using rules-of-thumb worked out in advance. It uses Information Technology investment as the working example, but the concepts apply equally well to other fields, although you may need to recalculate some of the rules-of-thumb used.

You can develop estimates that are accurate within a certain range, and that are better than guesses, in a few seconds if you remember some rules of thumb, and if you practice and refine your technique.

Detailed cost analysis and proposal-writing is important, and takes time, and there is definitely a place for it. But fast estimates are used to make high-level strategic decisions more often than you might realize. You should develop this skill.

Nightmare Scenario

If this hasn’t happened to you, it will.

You follow another person onto the elevator and, as the doors close, you realize the other person is your Deputy Minister (private sector: company President), on their way up to the board room on the top floor.

The deputy says hello and you introduce yourself. Then,


So, what do you do?

… Oh, you’re the leader of the IT development organization? Great. I’m on my way to a meeting right now, and it just occurred to me that it might come up that we need a system to do requirement-you’ve-never-heard-of-before. What would that cost?


I can send a business analyst to get your requirements right away, and have an estimate for you by end of week.


No, I’m meeting the Minister now. What’s your best estimate, now?

What often happens next

A number of reactions to this high-pressure situation are rather common, including, “No response”, “Rote inflated response”, and “Poorly informed lowball response”. Here’s how those typically go:

No response

You can think of all kinds of things that you don’t know right now. You don’t want to be anything but exact and perfect. So, you respond, “Sorry, Deputy, there’s no way to give you an estimate without going through our requirements and analysis process; we have to make sure we don’t miss anything.”

The Deputy says, “OK, thanks anyway”. When the opportunity arises later in the day, they remain silent, and the opportunity is lost. The Deputy remembers that you were unable or unwilling to do a fast estimate.

Rote inflated response

Young man with greedy, scheming lookYou can think of all kinds of things that you don’t know right now. You’re terrified that you’ll be held to an estimate that is too low and not have the time or funds to succeed; but “no one was ever fired for having money left over”. So, you “take a conservative guess then double it”. Essentially, you’re going to ask for as much as you think you can get away with. You can return whatever is left over at year-end, or use it for something else.

Most small systems probably cost $150K so you say, “It might be $300,000, and $100,000 per year ongoing?  Maybe more.” The inflection at the end of the sentence implies the “question mark”, re-enforcing that you’re really not sure.

The Deputy responds, “Really? Wow. OK.” Again, they don’t take the idea forward – it’s more money than they’re willing to invest – and the opportunity is lost. Or, even worse, they propose the idea, and are not believed. Your group’s reputation for inflated estimates increases.

Poorly-informed Lowball response

You can think of all kinds of things that you don’t know right now, but you hate to pass up an opportunity to get new work. You’re terrified that if you don’t get awarded this project, it might go to someone else and you’ll lose control. You know they sell a software package that does something like this at Best Buy for about $350 so it must cost something like that to buy or build. You’d need a computer ($3000 at Best Buy) and a couple of days to install it.

So, you respond, “Maybe $5000?”. (Again the spoken question mark.)

And the deputy responds, “Fantastic, thanks! Assume we’re a ‘go’ on this.”

Half a year later, a note written by the Deputy on a returned briefing note says, “You need another $50K and to hire another person? You said $5K!”  By the way, it’s performance review season.

What your response could be

You think for a few seconds while the elevator floor indicator ticks by: 3… 4… 5. Then, taking a deep breath, you say,

This is only an estimate – about $65K one time – that’s $35K salary and $30k capital – then $20K expense ongoing starting in year 2 for as long as the system is in use. There’d also be a small cost – around $10K – to decommission it at end-of-life. I’d need to get back to you on what current project would be sidelined to do this with existing staff. We could avoid that by using a consultant instead, for about $30K more. Don’t forget that the users might require training, and there would be an opportunity cost to take them off their jobs for that.

I could explain where those estimates came from if you like, or could get back to you with a more detailed analysis in a couple of days.

Looking thoughtful, the Deputy responds, “Thanks, that’s enough detail for now. I’ll get back to you if I need to follow up.” The project gets approved, and the actual costs come in within about 15% of this estimate. You’ve built up some trust in your estimating skills.

Where did those numbers come from?

Those figures were not fiction and they were not a guess. They were an estimate based on sound and defendable reasoning.

  • The labour estimate assumed this simple system would take one developer 3 months. The 3 months came from your experience with small systems. (Know how many months small, medium, and large systems usually take.) $500 per day for 60 days gave us the $30,000. (See below for where the $500/day figure came from.)
  • The capital cost assumed that we need to run this system on a server costing $10K. (Know your standard server costs!). We’d need 3 – development, production, and testing.
  • The ongoing expense assumed 1 day every 2 weeks from an employee (which is 10% of a $100K person, for $10K), and assumed 20% of the server cost annually for renewal, for an extra $6K. We rounded the $16K up to $20K. (20% of purchase cost is a standard rule-of-thumb for annual maintenance costs of IT equipment.)
  • 10% of purchase cost is a good rule-of-thumb estimate for the decommissioning of a system at end-of-life.

Do the homework for your domain

You can do estimates like that in a few seconds if you already know the various rule-of-thumb estimation values involved. These might be different for your field – but you can work them out, and you should.

Labour Costs

For labour, know how long typical tasks take, and know roughly what your staff costs are.

In this example, we’re talking about technically-skilled professional staff (CS or ENG). CS salaries range from $66K to $124K – but it’s a bell-curve since most of your staff are in the middle of this range. (i.e. you may have a few CS-01s and a few CS-05s, but most of your staff are probably mid-range, like CS-03.) If we do some kind of weighted average, we get an average salary of $93K. Add the 25% “benefits tax” that our finance group usually includes in calculating salary budgets, and we get about $117K as the annual loaded labour rate for a CS.

Do some simple math and it turns out that there are about 112,000 minutes in a standard work-year. That’s really close to the 117,000 dollars above, so the loaded labour rate for your average technical person is $1.04 per minute, or “a dollar a minute” to a pretty good approximation. That’s about $60 per hour, and just under $500 per day. Double that if you are using contractors – you are paying extra for their profit margin, their administration costs, and for not making a lifelong employment commitment.

$1 per minute for professional staff is a useful rule-of-thumb estimator for many purposes.  Use $2 per minute for Executive staff.

As an added benefit, this is useful to help you keep an eye on how long some decisions take.  If 5 technical people spend an hour deliberating, that’s 5 x 60 = $300 in labour costs.  5 executives: $600. Was that $600 spent making a $200 decision?

If your projects make heavy use of staff in a very different salary range, repeat the calculations above and know your per-minute, hourly, and daily cost for average staff.

Equipment Costs

If you are an IT manager, it’s important you know your average server cost; and don’t forget to allow for more than one if you need a development environment or spares.

If you are virtualized, or using Cloud, know the average cost to add an application, instead of pricing servers. If you are cloud-based, your cost will be expense instead of capital, and there won’t be separate “ongoing” maintenance or decommissioning costs – those are included in the Cloud service fee and are, in fact, a big part of the reason for using the cloud.

If you are not in the IT field, know what other equipment costs are often associated with your work. Office space? Vehicles? Specialized equipment? You might even have no standard equipment costs.

Grow your estimating skills using feedback

Do an estimate like this at the start of every project, even if you are not being cornered in an elevator. Do it yourself, with little or no research, before your experts do detailed costing and planning and fill your head with distracting details.

Then, after every project, compare what actually happened to your estimate. Of course it was wrong – it would be surprising if it wasn’t. But was it spectacularly or dangerously wrong? If so, why? What did you forget or estimate incorrectly? Learn and improve.

Important strategic direction-setting decisions are made with very coarse estimates all the time. Learn to use this process to your advantage by feeding it with good data.

IT Funding Models

Consulting firm The Right Door Consulting & Solutions occasionally publishes white papers written by their consultants. A couple of white papers I wrote were included in their collection and distributed at a recent government management conference. The following is the long version of one of these. (The formatted versions are available here: the short version that was handed out, and the longer version reproduced below.)

Use the right mix of funding options for your IT organization

Many years ago, I inherited an IT organization with a funding problem: they were coming to the end of a multi-year, but temporary, allocation of funding. Unfortunately, this temporary funding had been used to enter into ongoing liabilities, such as enterprise software licensing and hiring indeterminate staff. (Hint: don’t do this.) This prompted us to consider the various ways that mandatory and optional services could be funded in an organization, and how to allocate available funding in the most effective and justifiable way.

It is worth thinking about how your IT organization is funded. There are probably options you haven’t considered, and a mix of funding models can improve your financial stability, your client satisfaction, and the quality of your portfolio management.


Most IT organizations have a dedicated budget – a fixed portion of their organization’s overall permanent budget. This is a form of internal taxation: allocating a department’s budget is a zero-sum game, so the “tax” is funding that the organization allocated to the IT group instead of to other branches. It would be the same as if the IT group had no budget of its own, but then all the other branches in the department had a mandatory tax clawed out of their budgets and given to the IT group.

Thinking about a dedicated branch budget as a tax is useful, as it prompts us to ask how the tax is allocated (i.e. who didn’t get the funding that went to IT). Was it allocated according to the number of staff in the other branches, their budget size, or some measure of their IT consumption? Chances are that no such analysis took place – the department simply allocated “the funding IT needs” then allocated the rest to the other branches.

Taxation is a suitable way to fund certain things. First among these is what economics calls “public goods” – services that benefit everyone in a community, not just certain individuals. The classic example is street lighting, which benefits everyone, not just drivers. Many IT services are public goods – email, the telephone system, and cross-enterprise applications such as finance and payroll. All the hidden infrastructure that makes these things possible (e.g. the data centre) is also in this class.

Taxation is a good way to pay for mandatory programs, especially those that are unpopular or invisible, and is an appropriate way to pass on costs that you are receiving, from suppliers, as tax – for example, enterprise-wide software licensing.

However, there are disadvantages to a taxation model. The most obvious is that tax is unfair to non-beneficiaries. If an IT system is built and operated for the exclusive benefit of one branch in a department, making all the branches share in the cost will seem unfair.

Tax also discourages resource conservation, promoting waste. We have all known (or been), an apartment dweller who said, “Why turn the lights off? Power is included in the rent.” If IT clients pay a fixed amount for a service, whether they use it or not, there is no incentive to be thoughtful about what resources they consume. Frivolous and wasteful network usage is a common symptom of this problem. “If I pay a fixed amount for the network, whether I use it or not, why not stream ‘Dancing with the Stars’?”

Tax is also not very agile. Because it is hard to quickly add funding and the staff to spend it if additional services are urgently needed, and hard to quickly release funding if there is surplus, taxation promotes large, long-term enterprise projects. Not that that is a bad thing – but it doesn’t encourage or facilitate short-term quick wins.

Finally, a tax-funded organization should be prepared for intense scrutiny from their taxed base. Clients will want to know where their money is going and that they are getting good value. A tax-funded organization needs good bookkeeping, reporting, and transparency.


Cost-recovery is the other extreme on the scale. For example, look at the IT Consulting industry: you pay a well-defined rate for consultants, who will do exactly what you pay for and nothing more. You don’t get work you didn’t pay for, and you don’t pay for work you didn’t get.

This model can be applied to an internal IT organization. In its pure form, the IT organization would have no base budget, and would bill client branches for the total cost of all the work they do. Clients would pay the total cost of new projects done for their benefit and would pay a share of the cost of consumable services (e.g. network) based on usage.

The advantage of cost recovery is that it promotes better-informed business decisions. Client branches get what they are willing to pay for, and they are fully aware of the price of their decisions1I heard an IT group say, “if we charge the client the full cost of the service, including the ongoing operating cost, they might decide it’s too expensive and not go ahead”. To which I would respond, “Good! If they can’t afford it, they shouldn’t go ahead. If you can’t afford the car insurance, you can’t afford the car.”. Cost recovery also encourages conservation, since clients will use only what they are willing to pay for, which usually translates into using only what brings positive value.

There are also disadvantages to a pure cost-recovery model. On the other side of the above coin, cost-recovery might discourage experimentation and automation, since the innovator knows they’ll have to pay for the new service. Such concerns are often misinformed, as automation is often cheaper than the manual process it replaces, but the bill for automation is overt, while the cost of manual processes is distributed and hidden, and thus often overlooked and mis-labeled as “free”.

In a cost recovery system, we must prorate shared infrastructure and services. It wouldn’t be fair to bill the cost of a new data centre to the next client whose application request caused us to build one. We need to calculate the cost of the shared foundation and determine a fair way to add a share of it to each client’s bill.

This billing for “total cost” tends to make clients think that our costs are too high. They compare our proposed price for a new application to the number they saw on a software box at Best Buy, or how long their co-op student says it would take to build. They aren’t taking into account the data centre, network, foundation software, help line, power systems, operations staff overtime, etc.

Cost recovery also implies that the services in question are optional. If there is a bill for the service then, surely, I can say “no thanks” and choose not to purchase it. Cost recovery is a poor way to fund mandatory services. “Thanks, but I’ll just take the web application, not the IT Security option.”

Staffing a cost-recovered IT organization is difficult. Clients expect to be able to have anything they are willing to pay for, but this requires that there be staff available to do the work. Does the IT group staff for the demand peaks or the demand lows? How does it pay staff during periods of low demand, or have enough workers available during peaks?

Cost recovery also implies that the IT organization is just a competitive supplier – that the client can “price shop” and go elsewhere for their services. This is probably not allowed – IT is, in fact, a cost-recovering monopoly. Those are usually unpopular.

Finally, there is a cost for cost recovery. We need a billing system, cost transfer transactions, debt collectors, and additional budget planning and complexity. We need to include the cost of cost recovery in the cost we recover, and we need to be careful that we don’t simply transfer the burden of cost recovery to our internal finance group. We must set the system in place in partnership with them, and making sure that the budgeting transaction size and period are set appropriately.


As you might expect, we can get some of the advantages and avoid some of the disadvantages of both models by combining them: pay for foundation and enterprise-wide services with tax, and cost-recover services provided to specific clients.

For example, we could tax-fund the data centre, network, help line, storage, and database and application server layers, as well as enterprise-wide applications such as payroll, finance, and email, and then cost-recover development and operation of services for specific clients.

We can also simulate cost recovery without the burden of financial transactions. Stay with a fully tax-funded IT organization, but don’t allocate all of the funded resources. Set aside a sizeable capability and let clients “purchase” work from that capability by spending “IT Bucks” – some kind of token purchasing power that is corporately-calculated and allocated to the client groups. To have the desired effect on business planning, the “IT Bucks” need to be multi-year and transferable, allowing clients to save, conserve, and barter with them.

Example: Shadow IT and the Gold Standard

Any time resources or funding prevents the IT group from doing everything clients want, “shadow IT” may pop up – clients doing IT themselves because the IT group can’t or won’t. This is often a nightmare for the IT group because of the effect of the non-professionally-done IT on the enterprise environment.

One partner organization that I worked with several years ago took on the issues of shadow IT and IT funding in a single approach. They redefined the IT group’s primary role as to deploy and support application development capability – from the data centre all the way up the stack to the development environment, programming language, workflow engines, and a set of services such as storage, data base, user interface, user management, etc. Those services were well-defined, integrated, managed, secured, and accredited.

The IT group maintained a small cadre of business application developers available, on a cost-recovered basis, to build applications upon those services — not enough for all demand, but a number that was sustainable even in the low-demand seasons. Anyone else — client organizations, students, contractors — was also allowed to develop their own applications as long as they used those services and only those services.

Foundation services were pre-approved architecturally and accredited for security and end-user branches were not allowed to build or use competing foundation or services, or to omit mandatory ones such as security audit. An application built on preapproved services with preapproved tools was automatically approved for operation, including accreditation.

Clients with funds and no people would buy application development from IT, while clients with skilled people might prefer to build their own applications. The foundation was centrally-supported, while client-built applications were supported by the client, or support by IT could be negotiated and purchased in long-term deals.


The process for allocating funding for your IT organization is an important consideration, and can affect how projects are selected and prioritized, and what business decisions clients make. Funding models deserve attention, and even occasional re-consideration.