How do you help upper management understand this is not trivial stuff?

Question

Everywhere I've ever worked I consistently run into the same problem with management, they have no idea what is going on in the depths of an engineer's mind. Understandably, they're not developers so a technical explanation just won't do. How do the rest of you relay the complexity of a project to management after giving an honest estimate and they look at you like the lazy overpaid punk you only wish you could be?

Answer 1

Management love bullet points. Make an impressively long list of them, and they'll see how much work you have to do (you may even surprise yourself with the length).

They won't read them, but they'll get an impression of volume, which often sufficient.

Answer 2

Paraphrase from a talk by Alan Cooper: There are two kinds of managers, those who were developers and those who are afraid of developers.

Answer 3

I facilitate a lot of project retrospectives. Experience suggests that some managers gain better appreciation of the kind of thing a software project is after looking at the outputs of a retrospective, or participating in one.

Answer 4

A lot of this will come from you setting realistic goals early, making them known, and sticking to them. When you meet your goal, but not their unrealistic one, explain why (and face up to the music if you were wrong.)

Also, when you say "a technical decision just won't do", I disagree. Sometimes, if you take the time to explain it, even if they don't get all of the details, they can see that you understand what you're talking about, and not just trying to pad the times.

It won't always work, of course, but it's a start.

Answer 5

Unfortunately if you want this to be easier, you've got to stop trying to get them to be an engineer. You can try all the metaphors, etc you want, but at the end of the day, you are responsible for bringing the vision to execution - you are where the rubber hits the road.

So instead of trying to get them to understand that it's hard and get them to understand technical details, take leadership over your section of the project. Instead of trying to get them to understand what's not possible, offer up solutions. Don't question the vision - question only the means that you use to get it done, or find a place with another vision that you can get behind.

They need to know that you're on their team and that you are participating in creating the business solution with all the creativity you've got -- and that you're not just a coder.

Answer 6

Don't tell them, show them.

Answer 7

For effect, you can make a nasty-looking dot diagram of the dependencies, print it out 11x17, pin that to your cube/office wall, and refer to it on occasion.

(nasty meaning dozens and dozens of nodes with lots of tangled joins, not ugly-looking)

Answer 8

I've been stung by this several times. The best advice I can give you is to try to separate estimates (how long you, in your professional opinion, believe a task will take) from schedules (when your boss wants a unit of work finished). Give your estimate as a three part figure (worst case, best case, and most likely at the moment), and do not revise it due to management pressure. Having conviction in your professional ethics is the best way to convince others that your job is worthwhile, and will negate the "lazy punk" stereotype.

The best resource I've read on this topic is Software Estimation by Steve McConnell. It's very good at explaining how to represent your profession to management.

Answer 9

To some degree, a technical explanation is required. Even if you know your manager's not going to grok all the terminology, it's still a mistake to under-explain as a way to avoid under-explaining.

One way I've done this in the past is to imagine what I'm going to say, then replace any word I can't expect the manager to know with 'fnord' in my head and see how it sounds to me. If I can't hear why something is going to take long, the original sentence isn't going to help either.

First Draft: Before I can do that, I'm going to have to fnord the fnord. It'll take two weeks.

Second Draft: Before I can do that, I'll have to go through the fnord, re-fnord every fnord in there, then run them all through fnord fnording. Each one is about forty-five minutes to fnord and fifteen more to fnord. There are about eighty of them. It will take a couple of weeks.

The first draft gives no information. The second at least gives a sense of iteration, of time taken, and of tasks to manage. It gives the manager, whose job it is to see that the project gets done as efficiently as possible, something to glom onto when someone asks them why the project is going to take longer than expected.

This ties into one of the golden rules of managing management: The more you think about how to keep your manager employed, the smoother things will be between you.

Answer 10

• Use ranges for estimates
• Break work into small chunks which are understandable. (Maximum complexity of a week).
• Demonstrate your value to the business through delivered projects.
• Have the business do a cost/benefit analysis of outsourcing... then make sure you beat it.

Answer 11

Break down your time estimate into much smaller chunks of 2-3 days rather than simply quoting 60 days to achieve a task. It demonstrates the complexity of the task (similar to the bullet point list) and also helps your overall planning to determine whether you're on track or falling behind.

Whilst the project is running, keep track of time spent versus your 2-3 day estimate to assist in future estimates and also the scope of your team if you have multiple developers.

Answer 12

Thats the problem with abstraction, a lot of what we do as developers sounds easy in the big picture but is really quite detailed when you get down to the nitty griity.

I find working to a high level task list is quite helpfull, you can summarise the big areas and provide more detail for your own benefit. It gives the manager some idea of progress / what needs to be done without actually having to care about the fine details. It's also harder to argue with a list of concrete tasks.

I also find it helps to try and be as transparant as possible in terms of where you are on a project. E.g. at any given moment have a pretty good idea of what has been done, what needs to be done and where the elements of risk/doubt are in ypur estimates.

Finally once you've worked with someone on a couple of projects you get to know what makes them tick so you may have to fight some battles / make some mistakes before you settle on a way of working.

And of course theres always at least one person in everybody's life where things don't gel and its hard work (or maybe that's just me)

Answer 13

Talk about risk. That generally gets their attention.

Talk about what can go wrong, and how you're going to mitigate that risk.

Understandably, they're not developers so a technical explanation just won't do.

This is true, just don't dumb-down your answers too much. For instance, if you're talking about the need to properly validate and filter user input for a form, you don't need to talk about how SQL injection works, simply say "a malicious user can enter just the right combination of characters which can be used to gain access to the database".

Also, if possible, cite instances where similar projects did not mitigate these risks and the consequences of that choice. For example, "Project Q didn't do this and as a result spent two additional weeks recovering their data and securing the application" or "I read in [journal or news source] that foo.com had this particular problem and not only lost X million dollars but marketshare as a result".

Managers who do not understand engineers do understand risk. It is their kryptonite, and if you can articulate how you're going to protect them from it, they'll likely develop a greater appreciation for your work.

Answer 14

Be short and to the point -- but include some details that support conclusions or help managers with their decisions.

If you don't do filtering/summarizing of your ideas, they'll have to take a stab at it themselves.

Answer 15

Somebody already mentioned bullet points. I make a point of creating a report every week that includes several bullet point lists. Included in this are tasks completed, tasks left to complete and issues outstanding that require other people's support.

This shows some level of the complexity involved in the work you are doing, including work for other managers, support, maintenance, etc. It also shows progress.

It's even better if you can put approximate timescales against the items to set expectations.

Answer 16

Always mention something about how this will help in the future and help maintain an edge over competition. Don't say too much in technical jargon...

Answer 17

I believe the real answer is a combination of the 2 most popular so far. You have to take the technical details that you understand and turn them into things managers can understand. Most managers understand risk(as highlighted in the 2nd mast popular answer). They also understand things like total cost of ownership (when talking about writing maintainable code). They also tend to understand planning(think project plans) so if you can layout the technical details in terms of high level tasks(create module q, update module x,update database code, etc) and then provide estimates for each of these tasks, your essentially making a rough project plan for your manager so he can understand how much work you really do have to do.

Answer 18

Talk their language: risk, value, time, resources and money. Use a spreadsheet, show uncertainty in it. As an engineer, you do the project breakdown to a level they can understand.

Answer 19

If they honestly want to understand the issue but don't have the technical background, I've found that putting analogies into concrete terms can help them build a mental model.

You have to know them well enough to use examples they can relate to (sports metaphors, organizational structures, mechanical models) and it doesn't hurt to match your explanation to their sensory modality (visual, auditory).

Answer 20

Generally older business mindsets are not realizing how much IT is being baked into the break of their success. Technology is now a Business enabler and magnifier.

• Ask them if they know how it "works".
• Ask them if they believe anyone could be brought in to do it.
• Ask them what would happen in some scenarios and what should be done to prevent it.
• Ask them what they know about disaster prevention and recovery..

You may find that their ignorance or attitude towards IT generally shows in how important something is or isnt.

Answer 21

In the software business, I think we often get into trouble because someone somewhere in the chain of people between the customer and the developer has failed to say "no, this will [ take longer | cost more ] than you want it to". Thus, vast projects are started with many of the stakeholders believing that the project will cost much less than it eventually does.

Ultimately, as developers, we get to the point where we have to explain some variant of the same message to our management. My own experience is that often management has been pressured into "drinking the kool-aid" and is not willing to accept realistic information about cost/schedule from their staff.

This is why I believe the true path to the evolution and improvement of software engineering will be for software engineers to become licenced, certified, and legally liable for the work they do in just the same fashion as do other kinds of engineers. That way, you will be able to tell your management (just like civil, mechanical, electrical etc. engineers can and do): "I'm sorry, I can't sign off on this: It's not practical. I'd be legally liable if anything went wrong."

Personally, I can't stand how much the industry acts like the doctors of old, burying its mistakes over and over. I've seen dozens of projects launched on a wing and a prayer, go off and crash and burn, and the same cycle is repeated again on the next project. Another advantage of going to full licencing, certification, and liability of practitioners is that it would force someone in the chain to actually be accountable for the results.

However, I wouldn't hold my breath waiting for it to happen anytime soon... after all didn't you know software is both free and magic? ;-)