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,

Deputy:

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?

You:

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

Deputy:

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.

Lessons from Star Trek

At my last few employers I used to blog regularly and encourage other executives to blog. I will be reproducing slightly modified versions of some of those blog posts here. This one was intended to be a little “tongue-in-cheek” because I had a bit of a reputation as a nerd.  It discusses leadership lessons we can learn from watching Star Trek. To my surprise, it turned out to be, by far, the most popular blog post I wrote, and received, by far, the most comments.

Science Fiction Confession

I have a confession: I’m kind of a science-fiction nerd. I certainly have that reputation among my colleagues and get good-natured jokes and ribbing. Sometimes I re-enforce this by “stepping in it”. But, come on, when someone misidentifies a Jawa as an Ewok, or incorrectly mixes Star Trek and Star Wars metaphors, what is a person supposed to do?

Among the Sci-Fi I like, I like Star Trek. I used to rush home from school to catch the new episodes of the original series, and I was thrilled when the series rebooted years later.

I like STNG

My favourite Star Trek series was The Next Generation – known to fans as STNG. I liked it best, and I’m going to discuss some of the aspects I liked that I think are relevant to our work here. I’ll leave the pure fiction fandom for social conversation times.

First, for people familiar with the Star Trek franchise and the STNG series, when I say, “I like STNG”, I mean the “real” episodes. Not the first season, except for how happy I was that anything returned at all. (It’s amazing that there was a second season considering how bad the first was.) And not the silly episodes like the holodeck adventures – I always assumed that those were fillers during creative lapses and during the writers’ strike, although the holodeck episodes in the Deep Space Nine series were worse.

Second, for everyone else: yes, I know it’s fiction. That doesn’t bother me. We can appreciate good writing and can learn from and admire behaviours exemplified in good fiction. And I think the best STNG episodes were good fiction.

I like the world view Star Trek, especially STNG, presented, but my current comments will be limited to ways that world view applies to leadership and technology.

Leadership

The senior leaders in the series demonstrate a variety of leadership characteristics – some good, some bad. We can learn from all of them – but I’ll highlight a few of the good characteristics here.

Values

One of the guiding principles for the lead characters is to have a clear set of values, and to stay true to them. Their employer, The Federation, itself has a simple value statement – the “prime directive” which, interestingly, guides some episodes but is deliberately set aside in other episodes in favour of the personal values of the leaders. Captain Picard seems to have two personal values that override all other concerns.

One is “truth” – in several episodes he emphasizes that nothing is more important than seeking and revealing the truth, and he forgives serious transgressions when staff are open and truthful about them. An episode providing good example of this is “the Pegasus”, which ends with Picard saying to his first officer (while releasing him from confinement),

“When the moment came to make a decision, you made the right one. You chose to tell the truth and face the consequences. So long as you can still do that, then you deserve to wear that uniform. And I will still be proud to have you as my First Officer”.

Another good example is “The First Duty”, with

“The first duty of every Starfleet officer is to the truth… it is the guiding principle on which Starfleet is based.”

(It’s hard for me to recommend that episode as I didn’t like the Wesley Crusher character, but it is a good story.  Here’s the scene.)

The other is the fair and ethical treatment of people. While this is shown in many episodes, I particularly like a couple that involve Commander Data. I like “the Offspring”, where Picard disobeys an order, stating,

“Order a man to hand his child over to the state? Not while I’m his Captain”.

In “The Measure of a Man” Guinan guides Picard to realize that the Federation’s attempt to define Commander Data (a sentient machine) as “property” has deeper implications:

“. . . Whole generations of disposable people.”

“You’re talking about slavery.”

“I think that’s a little harsh.”

“I don’t think that’s a little harsh, I think that’s the truth.”

Strategy vs implementation

The leaders in the series do a good job of separating strategy formulation from implementation. The hard part, and where their attention goes, is in deciding what to do in a given situation. Actually doing it, once the decision is made, is only work, and is facilitated by their technology.

Roles and the chain of command

The Canadian public service has the unofficial slogan, “Fearless Advice, Loyal Implementation”. Many STNG episodes demonstrate these two roles: when options are being sought, provide advice, and argue for your point of view; once a decision is made, execute that decision.

While there are many episodes where this is demonstrated as a matter of routine procedure, the episode “Gambit, Part II” addresses it directly, when Acting Captain Data reprimands Worf.  It’s also a great example of a manager dealing with a performance problem immediately, firmly, clearly, and in private.

Communicate in the audience’s language

The series contains many examples of the importance of communication, especially of adapting it to the circumstances and of speaking to each audience in language they will understand. One is firm – even threatening – with bullies and Klingons, and one quotes regulations to hyper-bureaucrats. The best example of this is the episode “Darmok”, where the entire episode is based on the concept of a species whose language uses a completely unfamiliar structure, and learning to communicate with them.

Technology

Finally, a technology leader can hardly talk about Star Trek without talking about their technology. Some of their technology (e.g. teleportation and faster-than-light travel) is forbidden by the laws of physics as we presently understand them. Most science fiction writing has this problem – there would be no aliens or interstellar travel in stories without some way to violate these laws. While the series depends on these “forbidden” technologies, I like that the writing acknowledges this dilemma in subtle ways.

For example, a physical rule called the Heisenberg Uncertainty Principle prohibits macro-scale matter teleportation such as the Star Trek “transporters”. Clearly the writers are aware of this, because several episodes make passing reference to a system component called “the Heisenberg Compensators”, which presumably addresses this. I like that gesture.

However, a lot of their technology is not impossible in that sense – it’s only hard, or expensive, or something we don’t know how to do yet, but that they have figured out. The underlying premise is that they have a vast, almost unlimited energy source available. What could you do with nearly unlimited quantities of energy? Quite a lot.

Their technology, and its extreme adaptability, is enabled by highly effective system architecture. A real-time graphic display shows the operation of systems, at any level of detail. Interfaces between systems and components are standardized, so you can implement new interactions between systems merely by sketching what you want on the interactive display. “Let’s route the output of this system through this processor, then feed it into this system over here”. There are no concerns about how to do that – you draw the desired flow of energy or information and it just happens.

When I first watched these shows, this kind of flexible system interaction seemed like a distant future vision, probably fiction. Now, however, Cloud computing is close to making this a reality.

The series also contains numerous important nods to security. The ease of accessibility and connectivity of systems also presents a security vulnerability, and this vulnerability is the basis of some episodes. Hacking, viruses, authentication, encryption, and privilege management are all key to various stories. This is a good reminder to get the security right.

STNG is replaying on a variety of networks – Netflix, Crave, etc. Skip the first season (except as the basis for certain drinking games) but have a look at some of the episodes mentioned above. Even if you don’t become a fan, there are good lessons to be found.