Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I manage a small in-house development team for a large organization. We develop for both internal and external clients.

I find it impossible to educate the non-technical senior management about the importance of team work, testing, etc etc.

However, the most difficult thing is trying to make non-technical people understand what is realistic to expect from us in terms of running concurrent projects and timescales etc.

It is definitely still a case of people think we just press a few buttons and applications build themselves.

Does anyone know of a simple business case template for non-technical managers to justify the investment in my team's time?

share|improve this question

migrated from stackoverflow.com Jul 12 '11 at 8:19

This question came from our site for professional and enthusiast programmers.

Thanks everyone. I use Scrum and have even developed a simple interactive web report showing tasks, estimates,non-technical user stories, burndowns etc. I have also tried using existing systems as yardsticks. I can say things like "that is a 'system a' type system and that will take around xx months to complete - making our outstanding development queue now at x years." It all goes in one ear and out the other. –  Davy Oct 22 '09 at 13:55
It might be worth bearing in mind, that if they haven't fired you yet, they still believe you're doing a passable job. Although they might not like your estimates at all. –  Bravax Oct 22 '09 at 14:19

6 Answers 6

up vote 7 down vote accepted

It sounds to me like your senior management are not interested in how you deliver projects. They just want projects delivered.

So issues which are important to you, like team work, testing etc, are irrelevant to them.

What you need to do is focus on the different projects at a project level, and give accurate and timely updates as to their status.

Make sure you start delivering projects when you say you will, and gradually they'll start believing your estimates.

Possibly use any historical data you have, to back up estimates for projects, this will lead some validaity to what you say.

If that is unavailable, you can look on the web at similiar companies, and hopefully find some case studies which approximate your development time.

One way to present this would be a gantt diagram showing ALL the projects your team is involved in. Don't overlook infrastructure upgrades, or smaller projects as these mount up and effect others.

This will give your management an overview of exactly what's going on, and you can use this to educate them, as to the complexity of delivering IT projects. (Working with developers, external suppliers, hardware vendors, customers etc.)

Hope that helps.

share|improve this answer
Thanks for that, it all makes sense and I have tried it all. I think they have their head in the sands and no matter what you say - they just here "OK, that will be done, and that, and that and all without any extra resources". –  Davy Oct 22 '09 at 13:59
Sometimes that happens. Typically this results in stretched out delivery dates, and possibly buggy software. If they're willing to say which ones are more important, you could prioritise your projects so the less important ones have less resources allocated to them. –  Bravax Oct 22 '09 at 14:07

As the developer, it is your responsibility to write out a list of all the steps and individual activities required to complete the project. Do not be afraid of including technical descriptions and issues. Try to be as detailed as you possibly can. Only after you finish this list should you attempt to assign time to each activity. Use an heuristic formula to estimate additional time for testing and debugging. It will become easier the more you do it. This list is your primary means of communicating your work to your colleagues. They do not think you're slow, they just don't have an intuitive understanding of the technical issues like you do.

Lastly, after you finish the above exercise (making your to-do list), you will likely still come under pressure to reduce your time estimate. At this point, instead of decreasing your time estimates, rather ask which features should be omitted from the shipping version of the product. This completely changes the dynamics of such discussions, and they will be significantly more collaborative.

share|improve this answer

If they are not interested, do not try to attract their interest. Just prepare some scenarios for them, and let them choose. Take into consideration speed of delivery, cost of delivery and quality of the software and propose them some scenarios. If they object, (“we want super quality for lowest price in super short time”), you can ask them to learn something about software engineering to actually understand, why those scenarios look like.

If they only want to make a choice – propose them some scenarios like “lower quality in shorter time”, “best quality with additional cost”, etc. Try to use some arguments and address their business knowledge: low testing means cheaper product, but bugs will affect productivity and cost of your users (maybe they will tolerate bugs, because their junior front-end workers are much cheaper for them than your developers?). Just make some options and be honest. Let them choose.

And if they want impossible from you… quit.

share|improve this answer
I like it - quit :) –  Davy Oct 22 '09 at 13:56
Yeah.... if you quit, they would hire another guy.... and that guy will eventually quit too and so on... until they realize.. "hey, Davy was right, after all" –  Sam Oct 22 '09 at 14:03
@Sam: As Ed Yourdon ( amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X ) pointed out, second manager will have more power to say "your schedule is unrealistic". –  smok1 Oct 22 '09 at 14:28

I think you need to prepare a few scenarios for them about what might happen if, for example, adequate testing is not done. The key is not to prepare a doomsday, absolute worst-case scenario but give them a range of possible outcomes. The client might not be happy with the final product because of the number of bugs and they won't recommend you to other clients all the way up to non-payment and possible legal action. Non-technical people often think that bugs can be quickly fixed (and sometimes they can) but it's the bugs that don't get noticed right away that can do the most damage. Things like an incorrect payroll deduction calculation that might go unnoticed for months. These are the types of things that proper testing can help avoid.

In terms of timescales, I think the best thing you can do is build a reputation of providing accurate estimates. If you consistently overshoot your estimates or finish a lot quicker than estimated they are going to factor that into whatever estimates you give them in the future. If something comes up that will affect the timeline, like them wanting you to work on something else at the same time, let them know and ask them to prioritize your tasks.

share|improve this answer

Show them results because that is what they care about. Get some numbers.

If you can't produce results or numbers to back up your claims to them then your claims are baseless as far as they are concerned.

share|improve this answer

That sounds like Dilbert's boss.... "programming is easy, it's just a matter of combining ifs and some other words"... or something like that.


This is what I was talking about:


I think the best way is to involve the manager in some of your activities so he gains a better understanding of how development works.

Also, I guess there is a good book that can help you... it has a lot of interesting case stories like yours.

See this: Software Engineering: A Practitioner's Approach, by Roger Pressman.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.