Tag Archives: Management

Work Breakdown Structure

The Work Breakdown Structure (WBS) is a pretty well-known tool for managing projects. It is a formalized way to split a complex task into many small (and by that more easily manageable) parts. So instead of “install computers in rack” you have list with e.g. check availability of rack space, request network and SAN connection, arrange date/time with computer center, etc. This is probably a bit simplified, but you get the point.

I use the WBS a lot as soon as things become a bit more complicated. May favourite tool are spreadsheets, which have the following advantages:

  • Everbody can use them
  • You can send them around via email very easily
  • Versioning is easy (via naming convention or use of a proper version control system)

What attributes should be maintained per task? I have the following:

  • Task ID: Never use the lines from Excel. A simple re-sorting and you are screwed
  • Status: green, yellow, red
  • Progress: open, done, wip (work in progress)
  • Area: Whatever makes sense to you. Examples: architecture, infrastructure, project management
  • Owner: The person responsible for the task towards management. Please note that this guy is not necessarily the one who does (all) the work.
  • Due date
  • Description
  • Activity log: Whenever something happens for the task, make a note with the date and your initials (you may not be the owner)
  • Task ID cross-reference: Relationship to other task(s)
  • External cross-reference: E.g. task relates to specific section of document

Depending on your requirements you may need additional information. You can also leave out some of the things from above, although I would discourage that if you don’t really know what you are doing. This list has been developed over a number of projects and sooner or later I was always thankful to have them.

So what is the relationship of the WBS to a project plan? The latter is generally more high-level, contains explicit dependencies, is more used to communicate with management. In many cases one line item in a project plan is basically detailed out by a WBS

How to Give a Presentation

“Everybody who loves attending presentations, raise your hand! No one? Hey, come on.  ……  Still nobody?”

Ok, so why is it that you may get this kind of reaction (although probably not so extreme)? In my view the simple reason is that the majority of presentations is just absolutely poorly done. People prepare at the last minute, if at all, execute lousy on that already weak preparation and then get the appropriate reaction from the audience.  Well, perhaps I am exaggerating a bit here, but I am convinced that most presentations fall short of what would have been possible with just a little bit of extra effort.

So here are the absolute basics:

  • Know your audience in advance: If you have no clue who will be attending the session you are pretty much screwed. If you have prepared a presentation for techies and business people show up, there will obviously be a mismatch between them and what you say. So for those case where you are not sure, have a “plan B” right in your pocket. In practice that means that you have to prepare not one presentation but lets say 1.7. For the case of techies vs. business guys this means that you should also have some business-related content. How much backup you need, depends on the individual scenario.
  • A presentation is not primarily about slides: These days many guys out there seem to think “presentation = power point slides”. That’s just plain wrong. A presentation is about conveying content (a “message”) to the audience. The slides are a means to facilitate and support that – nothing more, nothing less. You probably know the design principle “form follows function”. For presentations it is “slides follow story line”. Because that’s what you are doing, you are telling a story.
  • The story line is crucial: All too often we end up in sessions where the presenter is going through a bunch of slides with no “big picture” behind them. This is when the story line is missing and the net-result is just poor. You especially see this when someone is giving a presentation where the slides were created by someone else. They basically tell one slide after another (or even worse just read them) and in the end you don’t know what the overall message was.
    I have had a particular experience when the presenter was showing a mixture of self-made and “external” slides. The start was with the external ones and I almost left the room after 10 minutes. Then came a self-made one and I thought “Wow!”. Things immediately improved dramatically and my overall rating went from “This is an insult to the audience” to neutral. With just a little bit of in-advance thinking it would have been a really good session and it’s sad that the opportunity was missed.
  • People want to be entertained: Think about what makes the difference for you between a good and an outstanding presentation. What was special when you last left the room and thought “This was really good, I’m looking forward to the next session of this guys”. For me the main differentiator has always been humour. Nobody is interested in “content only”. Of course content is really important, but people also want a good show. Don’t be mislead: You are not expected to be a comedian and crack one joke after another. But something amusing at the beginning (a so-called icebreaker) makes all the difference.
    What you choose depends very much on your personality because you want to be “authentic” here. It is also important to find a topic that allows you to smoothly proceed to the content side of things. Example: I was once looking for an icebreaker for a presentation about increased agility. A British colleague came up with a fantastic one about formula 1. So both parts were about speed and the transition from icebreaker to content went just naturally.
  • Not everything on the slides: Sometimes people think that everything they tell must be on the slides. I must confess to you that I once thought so as well and it’s just dead-wrong. The only job the slides have is to support your story line. Now you often want/need  to give something to people, either for later reference or because they missed the presentation. That’s a good thing to do but should not cause you to put everything into the slides. The right place for those details are the speaker notes.
  • A short presentation does not mean little preparation effort: In many cases it is just the opposite. The simple reason is that the less time you have for presenting, the more you must try to come to the point quickly and at the same time avoid loosing the audience because of leaving out a critical detail. My personal record is a 10 minute presentation that took a full four man-days to prepare.
  • The right level of animation: No animation at all during a presentation is probably just as wrong as having loads of them. To determine where it makes sense to hide things when the slide first comes up, think about the story line again. As it unfolds, so should the elements of the slide. If both sides go hand-in-hand you have the right mixture.
  • Text on slides: Be very careful with text on your slides because it tends to distract the audience from you. They can easily look at a diagram that supports what you just say and still follow your speech. But as soon as they start reading their focus is on the slide and not you any more. The two reasons why I put text  on slides are
    • quotes (e.g. from analysts) and
    • visualization for a line of arguments
  • Face your audience: There is no reason to look at the slides and not towards the people in the room. If you do, you either didn’t prepare well enough and need to look at the slide for remembering what to say; or you put too much text on the slides and even with lots of exercising were not able to memorize things.
  • Move around: Don’t stand next to your notebook all the time. For switching between slides mankind has invented cordless presenters; get yourself one.
  • Involve the audience: This is not always possible but makes the whole thing more interactive. Don’t ask people to do things that might “expose” them too much. Unless you know the audience well enough the best thing is probably to ask questions like “Who has done XYZ before, please raise your hand”.
  • Know thy time: You were (hopefully) given a slot with a certain length. Don’t exceed that time! It is unprofessional and unfair to the other presenters, because you steal their time. A couple of points here:
    • Practice upfront to get a feeling how much time you need; a rule of thumb is 5 minutes per slide.
    • Plan in a way that allows you to either leave out things or add some. Your advance planning of time will never be 100% accurate and this buffer will make you much more relaxed.
    • Take into account that people might ask questions.

There is certainly more but I think if you follow those points you already do a much better job than most people I have seen out there. Good luck!

The Danger of BCC

The title is a bit dramatic, admittedly, but there are some pitfalls associated with using the BCC feature of email programs. More specifically the combination of BCC and the “Reply to All” functionality can put you in a pretty bad position. And the reason is quite simple:

You put people on the BCC list because you want them to know about the email, but the regular recipients should not be aware of that fact. So far so good. The problem is that most email users don’t pay much attention how they got the email. They don’t check whether they were put on TO (regular recipient, action required from them) or CC (just for information, nothing to be done).

As a consequence, if you send stuff around with folks on BCC, they also do not realize that they are neither on TO nor CC. Instead they may think “I can contribute something here” and press the “Reply to All” button. Obviously the regular recipients will wonder how someone, who did not get the email (from their perspective that is), can say something about it. And a split second later all but the novice email users realize that you had put an unknown number of other people on BCC.

So you will have a trust issue here! Luckily this situation can easily be avoided and here is my advice how to do it: Never use BCC. Instead just forward the email to all those people that you would have put on BCC. Now, there might be folks around who argue that this is too cumbersome. And indeed, if you send 100+ mails per day, it may be disruptive to always change into the “Sent Items” folder and back.

However, if you have read my post about the “Getting Things Done” approach, you may remember that I recommend to have a rule in the email program that puts you on CC for all outgoing email. So just wait a few seconds until this copy arrives in your inbox and forward it then.

Business Analyst and Enterprise Architect

In a recent edition of their ZapFlash newsletter the guys from ZapThink (I could not reach their site when writing this, therefore no link is put in here) bring up a pretty interesting topic. They discuss the relationship between the role of a {en:business analyst} (BA) and that of an {en:enterprise architect} (EA). They put them much closer to one another than I would have done prior to reading this, which triggered some thinking on my side that I would like to share with you.

The core point, I think, is that both roles were “invented” in the attempt to link the {en:strategic} layer of the {en:organization} with the {en: operational} one. (Hm, can you think of this as an incarnation of the famous knowing-doing-gap?) This view leaves out completely the notion of business and IT, which would delude things for now. Both sides have realized (or were probably forced to) that in many cases there are significant gaps between what is needed and what exists in reality. So they have both moved from their home territory into “enemy’s land” in order to grab their share of the pie. This has narrowed the gap but not closed it.

What is needed is a role that coordinates and brings together the BA and the EA. It is in my view not realistic (and probably also not desirable) to merge EA and BA into one physical person. But the main problem, from an overall organizational point of view, is that they serve two different masters. They therefore have goals that conflict on a practical level, although the intentions point (hopefully) into the same direction. The result of this combination is that a lot of discussion, negotiations etc. takes place. And at the end of the day a compromise is reached, that nobody is really happy with.

Instead it might be worth thinking about a new organizational layer sitting between business and IT. BAs and EAs would be reporting into the same person and work on the same set of goals. The challenging thing would obviously be to identify those goals. But hey, this is true for all parts of the organization. On a very high level I could think of revenue (coming from the BA side, mirroring how well the needs of business are served) and profit (coming from the EA side, representing how efficient things are). This is certainly just {en: brainstorming}, but it illustrates the point.

An even better approach would probably be to take the line of thinking from the above paragraph and implement it into the existing orgchart. Hm, looks a bit like a matrix organization (anybody out there who really likes them?). Still, saving an organizational layer is certainly worth a reasonable thinking effort.

That’s it for now. I am looking forward to comments on this.

Meeting Minutes

Meeting minutes sometimes seem to have become a “lost art”. I mean, they are not rocket science, rather a bit dumb. Let me therefore share with you the in my opinion essential points.

  • If you want to follow only one advice, here it is: Write in a way that allows someone who has not attended the meeting to understand the minutes. This especially means that you must very carefully set the context for each topic. You get two things from that additional effort. Firstly, someone who has not attended the meeting will understand your minutes (surprise, surprise). Secondly, and perhaps more importantly, YOU will be able to understand your minutes in a few weeks. Chances are that you would not do so without setting context etc.
  • There is no such thing as a meeting without minutes. Depending on the type of the meeting you can decide to just write a short email that sums things up. But something should be written! This is the only way to ensure that people have a common understanding what has been discussed and decided.
  • Use a template, and please let it be the same template every time. It does not need to be extremely sophisticated but should support ease of reading. That means the reader should be supported in absorbing the content.
  • Each entry is clearly marked as a certain type. Usually you find: decision, information, action item. Add others as you need them (sometimes “status” is a different category).
  • Please only one (1) owner per action item. This person is responsible that the job gets done. This does NOT mean this person always has to do it in person (this is only one of several possibilities). He or she can also delegate it, do it together with someone else, etc. But he or she is responsible towards the meeting that the work is finished by the assigned due date.
  • Each action item also has a due date. There must never-ever be an action item without a due date. Period. This due date does NOT get adjusted when it is missed. Otherwise the pressure to work hard will be lowered (you don’t want that, do you?).
  • You should document who attended the meeting and who got informed about the outcome. So please put a list of attendees (also partial attendance, to be documented as such, counts) and a list of recipients into your document.

So nothing complicated here, right? One last word in terms of effort. Writing good meeting minutes takes time. Unless you are extremely fast, you can expect that the writing will sometimes take as long as the actual meeting. But this is normally time well spent. Especially if you are working for a client on a consulting project, you should be careful to document what was said.

So what should you do with those meeting minutes once you have finished writing them? Here is my take on it:

  • Send them to the participants and ask them to check carefully
  • Depending on when the next meeting occurs, people must either provide their feedback within a certain timeframe (I suggest 2-3 working days) or at the next meeting.
  • If nothing has been brought forward within the agreed timeframe, the minutes are considered to be signed off. This is critical for projects with external customers, but also good practice internally.

You can probably refine most of my points and also add quite a few more. However, these are the basics and if you follow them, you are most likely well above the average standard.

“Manager Tools” Podcast

My favourite podcast is Manager Tools, that offers an incredible amount of tips and useful background information on many aspects of management. A friend told me about it some 2 years ago and since then I’m hooked. The really cool thing is that all shows have actionable content. They typically last about 30-40 minutes, so I mostly listen to them when I commute to the office.

If you decide to sign in, which is completely free, you get a few additional shows. Believe me, they are worth it! For those that prefer to have some notes to go through and read, there is a professional membership available on a subscription basis. Also, there is a quite active community, so make sure to check out the forums as well.

“Getting Things Done”

Today I would like to tell you about a very effective way to organize your work. It is the “Getting Things Done” approach from David Allen. Some people argue that due to its simplicity it does not deserve to be called methodology. In my view this is a completely academic argument. On the contrary I would even argue that one of its main success factors is exactly that simplicity.

In a nutshell, whenever a new task comes in, you do one of the following things with it

  • You work on it right away
  • You delegate it to someone else
  • You decide to work on it later
  • You don’t do anything but ignore it

The nice thing is that this approach works very well with emails (most of which represent a task anyway). To make things even easier, there is a nice Outlook Plug-in that automates steps that would need to be carried out manually otherwise. There is also a book describing things in a great more detail.

I personally never read more than the first 50 or so pages, because the core principles are so easy that they fit onto a few pages. Perhaps I missed some great points and would like to hear from you if you think so. I did, however, spend a few bucks on the Outlook plug-in which is a great tool.

One tip for the plug-in here: Set up a rule that puts you on CC for every mail that goes out. You can then either have it sitting in your inbox as a reminder. Still better is to treat it just like any other email and create a “Waiting for” task from it, while you wait for a response.

Related posts

What is Time Boxing?

This is a term from the (software) project management area. It basically means that deliverables are not fix in terms of content, which is the “normal” approach. The latter means that something has been agreed-upon as scope and will be delivered when that has scope has been implemented. Hopefully the planned deadline will be met, but it can be sacrificed in order to deliver the full thing. With time boxing, however, one is willing to reduce the scope in order to meet a deadline (goes hand-in-hand with the MoSCoW method). You therefore often find it in the following contexts

  • Agile projects
  • “Political” projects where it is more important to keep a date than functionality

For a more thorough discussion check out this article.