Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm presenting a software design for approval today and as I'm going through the hundreds of pages of design documentation, cherry picking what's important, I'm unsure if I should start with the activity diagrams or use cases. I was thinking of having it stacked like so:

  • Activities Diagrams
  • Use Cases Diagrams
  • Sequence Diagrams
  • Class Models

I've spent the last 7 months of my life creating this and I want it to be presented in the most logical order and done with.

share|improve this question
When presenting a software design to upper management -> keep your resume up to date. – ThinkingMedia Jun 14 '13 at 15:17
So you're only now, after 7 months looking for approval from upper management? – Telastyn Jun 14 '13 at 15:19
Exactly how technical is your management – Rig Jun 14 '13 at 15:29
@TimLieberman Good luck dude. I hope it all goes smoothly for you today. – ThinkingMedia Jun 14 '13 at 15:35
IMO if the management left 7 months to this without iterations, reviews, other interest, I doubt that would change today, and the presentation will be fairly pointless. So just take it easy. The dice was thrown half year behind. – Balog Pal Jun 14 '13 at 15:50
up vote 7 down vote accepted

You should start with one diagram. What are the big parts of this software?

Talk about the responsibility of each at the high level, focus on tying in the boxes to their understanding of the business.

After the one high level diagram, I would get 1-2 layers more detailed. I would make sure that you take time to let people ask questions.

Do not try to let them get mastery of the design, sell them on the idea that you know what you're doing, and that more often involves making them know that you know the domain (what terms to use for each area, what insights relate between them). They often can't judge a software design or your technical skills.

If they think you know what you're doing, that's what will drive their approval more than any logical presentation.

share|improve this answer
I believe once I deliver a final version they'll have more trust in me and I won't have to spend so much time designing in such detail. Around here the worst thing you can let the vp catch wind of is your coding without her graces. – Tim Lieberman Jun 14 '13 at 15:38
yes: "...tying the boxes to their understanding of the business" - especially as to the benefits the boxes provide to the business – Steven A. Lowe Jun 14 '13 at 16:55
Sounds like it might pay to be a little bit boring if you want them out of your hair. Otherwise you'll have to do these presentations over and over again ;) – Erik Reppen Jun 15 '13 at 2:44

The upper management folk that I've met tend to be focused on

  • Will it do what I want/need?
  • When will I get it?
  • What are the risks involved?


  • Have you done your homework (and/or 'do you know what you are talking about?')

Showing them class models might be useful to show that you know what you're talking about, but beyond that you'll bore them to tears. Not recommended.

Stick to a very high level overview, sound confident, and be prepared to back up anything with details.

Don't do any on-the-spot engineering. You will get it wrong. If asked a complex question, write it down and get back to them.

share|improve this answer
+1 concept + schedule + risk is what they will care about – jk. Jun 14 '13 at 15:30
This was my first time having to do a complete waterfall approach. I don't plan on going into depth with the class models just a walk through. – Tim Lieberman Jun 14 '13 at 15:32
This was also my first time having to do this much design before any prototype or p.o.c. – Tim Lieberman Jun 14 '13 at 15:33
Pay close attention to what they say, body language, etc. and be prepared to skip a lot. If you skip over something that interests them, they'll definitely ask about it. Boring them with details won't help your cause. – Dan Pichelman Jun 14 '13 at 15:35

Depending on how technically inclined the audience is, you might want to leave some parts out, and add others. If you show them class models, will they understand? Will they care?

Most of the people that I work with who would count as "upper management" do not care very much about implementation details (it sounds like this is what your presentation focuses on), they mostly will care about:

  • introduction and general overview (what is the point of this system?)
  • high-level architecture (how is it built - at a high level?)
  • user stories (what can a user do with this system?)
  • data model (sometimes these are useful/necessary, but it depends on the project)

(I would run the presentation in that order as well)

Some members of the audience might care about the other types of diagrams (probably the use-case diagrams more than the others), and the diagrams can be useful in explaining other parts of the presentation, but I'm not sure I'd launch into them straightaway or make them the focus of the presentation.

Of course, if your audience is highly technical and want to see this kind of info, then go for it! But I'd still start off the presentation with some kind of general overview, just to give some context for the rest of the presentation.

share|improve this answer
I love the idea of a general overview first. They'll understand the class diagrams. I've put together 55 pages of high level structure and abstract general uses. Pretty sure its my job to do the actual analysis of entire design. This is just my first large project that I'm in charge of and I think they just want to make sure they can let me off the leash and get going on assembling team and integration. I won't forget to give you check but would like to see if anyone else has anything first. – Tim Lieberman Jun 14 '13 at 15:27

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.