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.

  • 4
    When presenting a software design to upper management -> keep your resume up to date.
    – Reactgular
    Jun 14, 2013 at 15:17
  • 3
    So you're only now, after 7 months looking for approval from upper management?
    – Telastyn
    Jun 14, 2013 at 15:19
  • 1
    Exactly how technical is your management
    – Rig
    Jun 14, 2013 at 15:29
  • 3
    @TimLieberman Good luck dude. I hope it all goes smoothly for you today.
    – Reactgular
    Jun 14, 2013 at 15:35
  • 2
    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, 2013 at 15:50

3 Answers 3


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.

  • 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. Jun 14, 2013 at 15:38
  • yes: "...tying the boxes to their understanding of the business" - especially as to the benefits the boxes provide to the business Jun 14, 2013 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 ;) Jun 15, 2013 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.

  • 1
    +1 concept + schedule + risk is what they will care about
    – jk.
    Jun 14, 2013 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. Jun 14, 2013 at 15:32
  • This was also my first time having to do this much design before any prototype or p.o.c. Jun 14, 2013 at 15:33
  • 1
    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. Jun 14, 2013 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.

  • 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. Jun 14, 2013 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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