How to make non-technical management more realistic when it comes to developing sopftware

Question

I manage a small in-house development team for a large organisation. 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 definately 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?

Any advice would be most welcome.

Thanks

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.