Category Archives: Project Management

PM#, Project Management

PM#3 – Use e-mail properly

4 Comments

E-mail can be a hinderance for three reasons:

  1. Unless you are very strict, most folks find themselves checking e-mail more than three times per day. This is especially true if your e-mail application has a notification facility whereby you see and/or hear new e-mail arriving. It’s very difficult to resist the urge to go and read new e-mail. Worse, in open plan environments, it’s possible to hear other peoples’ new e-mail arriving.
  2. E-mail, as an application, has history, it has etiquette, it has a modus operandi. Very few people, in my humble opinion know how to make good use of e-mail. This is especially true for “newcomers”, i.e. those folks who have joined the e-mail bandwagon late and don’t realise that there are written and unwritten rules that should be understood (notice I don’t say ahered to, rules can be broken if the timing is right, but that’s another posting!)
  3. E-mail has no real means of helping us manage our to-do list, it doesn’t help us manage those e-mails that require us to respond to, nor does it help us manage those e-mail for which we are awaiting a response. As project managers, we find ourselves dealing with collections of issues, requests for information, decisions, etc. How do we solicit such data? We use e-mail. How do we track who has responded and who hasn’t? Suddenly it becomes very difficult.

One of the e-mail rules that I like to adhere to however, is one that is all too often broken by others. If you find yourself in the CC section of an e-mail, i.e. not in the TO section, this typically means that the e-mail, for you, becomes a FYI…for your information. Your response, unless solicited directly in the e-mail, is not required. Should you choose to offer a response, you should apologise for interjecting from a CC.

Managing by e-mail is also rather difficult. I know some folks work on a “zero in-box” policy whereby e-mails are converted to tasks (we’re talking about Outlook here) and thus you have a prioritised list of things to do. This works, however I think the problem of information management, and e-mail falls into this category, is a much more difficult arena, and one that is not served by a killer application. Of course, managing all this properly brings with it the need to classify, attribute, associate, infer, etc. links between items, prioritise items, and so on. Whilst work is being performed in this area, all we can do today is learn to use e-mail properly.

Don’t let e-mail rule your life – you don’t need to check your e-mail more than three times per day (if somebody tells you that they have just sent you an e-mail that requires your attention, you may of course check your e-mail in between times!)

Do try to keep your immediate in-box cleared down to a reasonable size, I prefer to have less than 20 items “in my face” when my e-mail client(s) start up. Use folders and colour-coding (if available) to help you sort’n’prioritise – not to the point that it overcomes point 3 above. Generally speaking, I’ve noticed that I have very few e-mails whose lifespan is more than 7-10 days – as such, I have a folder “older than 10 days” which can be used as a manual dumping ground, or automated via a rule. Your threshold may vary, but try it, you may be surprised.

You don’t need to keep all trivial e-mails, move them to a “trivial” folder, or better still, delete them.

I will often include myself in the CC list of an e-mail. This allows me to clear out my sent items folder fairly frequently. If your e-mail client offers you “sent item”-specific features, such as delivery/open tracking, this might not be an option for you (but only if such tracking is required).

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

PM#, Project Management

PM#2 – Focus on the project

3 Comments

In Vienna, April 2004, Ken Schwaber, co-founder of Scrum said to his class:

“Don’t procrastinate, do something, no matter how small…something that moves the project forward”

I’ve kept that quote close to hand ever since. In fact, I even use it in my Scrum presentations (more here – registration required)

The crux behind “Focus on the project” is this:

We all suffer from an uncanny ability to be sidetracked or to be distracted. This is not good for the project.

Distractions, as Clarke might say, are evil. I certainly agree, distractions are the work of the Devil.

I find myself distracted by a number of things (apologies if these sound like rants…they are sort of!):

  1. Passers by. I’ve been travelling a lot over the last 18 months, so when I get back to my desk I’m invariably greeting with the response “oh, you’re back…”. And being an IT guy, the next question, after the usual exhchange of pleasantries is “…I have an Excel problem…have you got a minute?” (Of course, sometimes it’s Word!) As noted earlier, “a minute” usual means five. Getting back to what I was doing after a five minute gap can be a chore.
  2. The telephone. The telephone’s great for getting quick decisions and I favour it over a series of e-mails (this is the subject of a future posting). However, just because I have chosen to answer the telephone, typically out of politeness, it doesn’t mean that I’m at your disposal. Please ask me: “is now a good time to talk?” or “do you have time to talk?” Better still, if you’re call isn’t that important, send me a single e-mail asking me to call you when I’m ready. Telephone interruptions tend to be continous, once a caller realises that you are already on the the ‘phone, they’ll tend to keep trying until they get through. Apart from the obvious waste of time and resource, it means you suddenly end up with two (or more) ‘phone calls back-to-back. This is really frustrating as it feels like you’re destined not to get on with the task in hand, i.e. focus on the project.
  3. Folks who don’t realise the importance of what’s being done. I’m sat here in my study typing this post, to all extents and purposes in the eyes other folks, it’s something that can be done later…because all I’m doing is staring at the monitor. Creativity doesn’t work 9-5, it doesn’t always manifest itself in swish graphics on the screen or reams of fancy looking text. Similarly, it’s the weekend…my deadlines have been published for long enough now, but still I’m just perceived as sitting in the study twiddling my thumbs…my to-do list isn’t at all important!
  4. Doing something for doing something’s sake. It’s nice to get ticks in boxes, little jobs complete, but ask yourself: “how important was that tick in the box activity?” It might have been important to somebody else who needed the tick in the box, but did it really help the project? There comes a time in a project when a particular avenue is closed off and another route has to be examined. Some folks will expect the original avenue’s work to be completed such that proper closure can be achieved. Invariably, you’ll find yourself creating documentation or doing work that will not be used and merely gets the requestor a tick in the box – this kind of distraction does not help the project and serves to slow to you down.
  5. Poor use of e-mail. A future posting will cover appropriate use of e-mail…as a distraction, “e-mail ping pong” is a real pain. E-mail is a great tool, but some folks treat it as “work postponement device”. This scenario typically occurs when you pass work on to somebody, you may spend some time crafting a very succinct e-mail making sure that you pass the request/work over neatly. Imagine your surprise when the reply comes back very quickly with a question that essentially passes the work content back to you? I’ve seen this trick referred to in other postings as “sloping shoulders” – the uncanny knack of not accepting a work package! I’ve also seen this scenario referred to as “answering questions with questions.” The distraction element occurs as you have to read the question and then re-plan the distribution of that particular work package.
  6. Too much work. Yes, I agree, this is a strange one. I find myself, and see others, being distracted because they’ve got too much work to do. In this distraction scenario we find ourselves flitting between tasks/activities, not really focusing on any task for too long. We essentially fall into the “multi-tasking is evil” camp, but that’s another blog post (#7, in draft format, coming soon).
  7. Too much travel.

    8. Travel takes its toll; downtime in airport departure lounges can be harnessed, however invariably, I find myself fidgetting and wanting to get on with some work, i.e. move the project forward. However, I usually end up reading a technical book, or a novel (this is sometimes better as it frees the mind, allowing the subconcious to “do what it has to do”) I’m a great believer in conference calls and LiveMeetings for bringing folks together “face to face”.

In summary…
Do what you have to in order to reduce the number of distractions that are plaguing you. Make large chunks of uninteruppted time available to you and your project – it’s the only way you can make significant and productive progress.

Even if you publish your deadlines and to-do list, sometimes you will find that you need to reinforce the importance of it to others.

Alway ask youself, “is what I’m currently doing helping the project?” If it’s not, then it’s periphery and you should re-prioritise your work basket.

It’s not just about “you” focusing on the project, it’s also about getting the project team to buy-in to a similar focus otherwise you’ll find yourself threading water (if you’re lucky). I know it’s difficult, but if you have folks on your project who have interests other than the project in hand, it’s important to have them drop that interest such that they can focus on the current project.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

Project Management, Rants

Agile:Rant: If you do some of the work…

1 Comment

Here’s a snap of the peaches we bought from our local big-name supermarket:

unlucky for some

“Ripen at home”. What’s that all about? I have to do some of the work here…and I’m still paying the same price. I don’t see any payback when I get to the checkout, what’s going on here? Does this mean I’ve bought a product that isn’t ready to use when I get it home?

Surely they should be cheaper? After all, they’re getting picked earlier, thus freeing up space on the peach tree for the next lot, thus…oh, I see, early release means earlier return on investment (and in this case earlier repeat growth). May be we software folks could learn something from this…

Incidentally, I’ve just realised what I’ve done here – I’ve provided some meaningful hints about this posting in the title (agile:rant) and in the categories (project management, rants)…this is exactly the conversation Korby and I had during TechEd 2005. Thoughts on classification, attribution, taxonomy, intelligent searching…coming soon.

PM#, Project Management

PM#1 – decision making

3 Comments

Many projects fail (are shelved, go over budget, over schedule, suffer serious scope creep, suffer serious scope “minimalisation”, etc.) because of inappropriate decision making.

Inappropriate covers a whole multitude of common mistakes, such as:

  • Inaccurate
  • Untimely
  • Overruled
  • Conflicting

Inaccurate decisions
It’s fair for a project manager to expect some support from the project’s stakeholders and any person or group who may have information to offer. We might refer to these persons or groups as centres of competence, i.e. folks who know a thing or two about how part of the project should work. For example, if the project required a list of activities that we could charge expenses to, we might expect to go to the payroll (or possibly human resources or finance) function and request it from them.

An inaccurate decision is one that the original centre of competence believes to be 100% accurate in their eyes, but is actually somewhat out-of-sync with what occurs in reality. Unless the project manager has domain-specific experience, it is unlikely that he or she will be able to spot an inaccurate decision (even with rigorous testing, inaccurate decisions will slip through the net).

Inaccurate decisions usually surface during an examination of workflow. The most common workflows through a project or system will be clearly defined, workflows that are specific to a small number of individuals or have special-case processing and calculation behind them, are typical candidates. Fortunately, if inaccurate decisions are caught early, their impact can be prevented from reaching project completion where the cost to rectify the inaccuracy is significant.

Luckily, if the project team is domain-aware and inquisitive, such inaccuracies may be surfaced through the use of a bottom-up analysis of the workflow and the decision. This involves the project team taking a pro-active role that plays the part of a “what if” analyser. Each step of the workflow is examined and the decisions that have been made are applied. Often this step will involve the use of mock-ups or worked examples that highlight the inaccurate decisions. The mock-ups and worked examples serve a second purpose: they can be used to invoke discussion that leads to the correct decision being reached. If this activity requires that a user of the said workflow is brought in to assist, so be it: they may have more questions that cause the decision to be invalid rather than just inaccurate. It’s better to let an decision become invalidated rather than assume that “it’ll come out in the wash” – this never happens, things always get worse rather than better.

Untimely decisions
These are less common. Such decisions are made too early in the project and are often geared up to get ticks in boxes or to endear decision makers to the project team and others outside of the project team (“Look at me, I’m co-operating on “high-profile” project”). In reality, early decisions are often revisited downstream as the circumstances surrounding the original decision and the question that prompted the decision to be made, change considerably.

Decisions that are made too late, i.e. after the fact, are just as bad. Not just because they are late, but because invariably a project assistant, a secretary or even a project manager have been repeatedly trying to get the decision made…and this will involve wasting a lot of time visiting the decision maker, e-mailing the decision maker and possibly even going to the decision maker’s upstream line manager (which does the project morale no good whatsoever). By virtue that time is being consumed chasing the late decision(s), the project schedule takes a hit as it is wasted resource (they’re not concentrating on moving the project forward).

Overruled decisions
Sometimes the simpler decisions are no-brainers and are often made by the project team on the premise that the decision maker will simply agree with their choice. The kinds of decisions we’re looking at here are the blindingly obvious ones. For example, a decision regarding XYZ has to be made. There are three possible choices for the decision maker to evaluate, however in reality only one will ever be acceptable: the obvious answer.

Despite their simplicity and their obvious answers, the decision maker steps in and overrules the obvious answer with one of their own. Sadly, this egotistic approach is often to the detriment of the project. A useful salt test for this scenario is for the project team to select the obvious answer and condemn one of the other obviously incorrect answers. The decision maker often homes in the condemnation and puts the incorrect answer forward as their decision. The time required by the project team to backtrack and undo an overruled decision can be considerable, invariably the project schedule takes a hit.

Conflicting decisions
In my opinion, these are the worst of all. These are decisions that give project managers a false sense of progress, they are decisions that allow ticks to be put boxes, near term work plans to be updated and the next set of tasks to be considered.

It’s only later that the real truth is discovered when another person or group provide their decision, only for the project manager and the two (or more) parties to realise that a conflict exists. Typically the conflict arises as a result of an uninvited person or group volunteering the decision or information surrounding the decision. At least with the conflict out in the open something can be done with it: we should therefore be grateful that an unsolicited conversation has resulted in the surfacing of a project impediment.

However, there are times when a conflicting decision arises because there are too many domain experts or too many stakeholders wishing to exert their influence on the project and its outcome. This is more commonly described using the phrase: Too many cooks spoil the broth… Such a scenario sees much indecision, much argument and much oneupmanship – none of which are good for the project or the sanity of the project team.

In summary…
Decisions really need to be timely and accurate and they need to be made by a person or persons who are qualified to make the decision. The decision maker also has to have the support from the project team, the stakeholders and those outside of the team such that the decision does not conflict and is not overruled. Decisions that affect more than just the person making the decision, such as employees, should be examined with a view to understanding how the decision will be received (consultation breeds acceptance). Decision making processes that demonstrate the first sign of oneupmanship should be terminated immediately and the offending parties advised of their faux pas.

If necessary, create a decision log, but be sure to include at least the following:

  • decision scenarios (an explanation of the decision’s origin, why it needs a solution)
  • decision originator (name)
  • the decision maker (name)
  • the date the decision was raised
  • the date a decision was made
  • the signature of the decision maker

And if you do create such a log, make it visible to the stakeholders, the project team and other interested parties. You would be surprised how quickly decisions are made when they are in the public domain and visible to more than just the original decision maker…more so if you’re able to colour-code decisions that are aging decisions.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

General, Project Management

Blog it, write it down, publish it: communicate and organise

2 Comments

Clarke has been lamenting about how so much of his conversation/experience seems to live in his blog – granted Clarke was lamenting to me over a pint, he didn’t actually publish anything about this issue.

However, I am finding that the older I get the more that I have to remember, and since my brain feels like it never stops, I write a lot of stuff down. But recently, I’ve started to add some structure to my thoughts (please don’t laugh) and have a number of blog postings sitting in my drafts folder – you might get to see some of them, you might not.

In May 2004, when I finally arrived in blogsphere, or so I like to kid myself, I struggled for blog content. Now, pretty much a year later, I’m tripping over content. Of course, having content is one thing, finding the time to write it up and blog about it is another. This is especially true as, currently, I don’t blog during office hours.

Similarly, some blog content might not be suitable for public consumption, so now I realise why some colleagues have two blogs: one that is publicly visible, the other that is totally private. Wherever you blog, it doesn’t matter, because when you do blog, the act of writing something down and hitting the save or publish button has the psychological effect of clearing it from your mind. In reality however, it has the opposite effect: it firms the blog posting up in your mind. Well, it does for me at least: your mileage may vary.

With that thought, I am now very much in favour of blogs for project management. Not that I was ever against them, I just hadn’t made my mind up until recently. Blogs are important communication devices, teams can gain access to project specific blogs, publish their own content and generally use the blog to organise the project’s artifacts and facets.

With careful use of RSS, blog content can be pushed to team members. Prioritisation of content can be organised via the frequency at which the project feeds are polled: my RSS aggregator lets me configure the feed polling time on a per feed basis. I have important feeds polling every hour, less important feeds every six hours.

“But”, I hear you cry, “why not use e-mail?”

E-mail is great, but how often have you ended up becoming embroiled in a massive exchange of e-mails over something trivial? Try organising a meeting spread over two or more geographic locations with more than five attendees and you’ll soon find yourself dealing with an in-box full of “I can make the 5th, but not the 7th”, etc. Anyway, this is a deviation from this posting – I’ll be writing more about the proper use of e-mail in one of my project management posts later this month.

Anyway, I’ve said a lot in this posting. I’ve hinted that I’m in favour of using RSS to improve communication, and as I noted here, I will be writing an article about the subject: Using Really Simple Syndication (RSS) To Improve Corporate Communication.

Project Management

Project management – a series of postings

1 Comment

This is an early announcement that I will be publishing a series (i.e. more than one) of posts in the Project Management category.

Each post will cover a specific topic; the first post will cover Decision Making. The posts are my own musings and are based on what I have either seen, been told about, read about or experienced/witnessed (over the last 15 years). Both good and bad issues will be covered.

I might get the order of the topics wrong, however I’m hoping that writing them down will mean they’re not buzzing around in my head – you may or may not be surprised to learn that writing can actually be therapeutic. Once something has been written down, your mind immediately starts thinking about other stuff, well mine does (usually) and since I’m planning a lot of education for June/July, clearing my mind of some thoughts is a good thing.

The first post will appear later this week.

Project Management, Scrum

Agile project management using TargetProcess

I’ve just finished reviewing TargetProcess for The Delphi Magazine.

TargetProcess is a fully integrated “on-line” tool that aims to help us manage the lifetime of a feature and it does so in four key areas: requirements management, project planning, project tracking and bug tracking. What makes TargetProcess unique from traditional products in this space it the fact that it is centred on “agile” approaches to product development. Agile approaches tend to be iterative approaches, focusing on lots of small product releases as opposed to one major release like those we see with traditional “waterfall” development methodologies.

I was pleased to see TargetProcess offer direct support for Scrum, eXtreme Programming, releases, iterations, user stories, tasks, bugs and time allocation. It goes a long way to help us convince folks who are used to the waterfall model and all the frequently unnecessary upfront planning associated with it, that the flexible world of agile can be managed with the bare minimum number of artifacts and without the need for a fixed project plan. In other words, TargetProcess might help you sell agile to those who don’t believe it works. (Further discussion about “selling agile” can be found here.)

Anyway, you’ll need to subscribe to The Delphi Magazine if you want to read the full review!

Follow the TargetProcess blog here.

General, Project Management

Reactive or Proactive?

I found this over at Frank Patrick‘s blog.

Unfortunately, it’s rather close to home for me. Invariably, my To Do list for the day has items carried forward to the next day. This happens despite good efforts to avoid being an e-mail monkey (I try to check e-mail at three specific points during my working day, morning, noon and departure time less one hour). However, sometimes the ‘phone rings and I hear: “did you get my e-mail?”. Doh!

And then there’s the ‘phone. Folks don’t do it on purpose, but they do make a ‘phone call without realising that what you’re currently working on is important to you and has to be completed by 1600. Sadly, they expect you to give them your full attention. Your priority is explaining this schedule pressure to them such that they can call you back at a more suitable time…however the interruption still hits hard. I won’t mention my mobile ‘phone’s operator name, but suffice to say there are plenty of everyday places that I can’t get coverage! (So finding a spot with no mobile ‘phone coverage is easy!)

The location of my desk doesn’t help, it’s really close to the office’s kitchen door, so there’s a lot of human traffic…and I’m sure you all know what happens when office-folk see an IT guy: “oh, that reminds me, have you got a quick minute, my PC is doing something peculiar”. I usually respond with “a minute’s 60 seconds” and soon end up spending over 5 minutes away from my desk. I can only guess that “quick minute” means “more than 5 minutes”. Anyway, I digress.

I also suffer from being too helpful. It’s difficult to tell work colleagues to “clear off and raise a helpdesk call” (I was advised to use stronger language, but I’ve dumbed it down for this posting). Of course, with well-known colleagues, we do go through the ritual of “clear off”, “raise a helpdesk call”, etc. and it’s followed by some humour and a “quick minute” of my time.

So, I’m afraid to say that I find myself being too reactive. I am,however, going to take Anita Sharpe’s advice and see what happens (although I’m not sure about the shutting my computer down at 2030!)

Meanwhile, what am I trying to say in this posting?

  1. We can become less reactive if business takes the opportunity to educate users such that e-mail becomes a communication tool, not a stick for prodding folks into action.
  2. Should we make some or all of our schedule publicly available? Scrum promotes this visibility for project related progress, perhaps I’m hinting that we should adopt Scrum practices in other aspects of our lives?
  3. Other folks have priorities, we should respect that. Without wishing to boast, I only use the ‘phone when it’s absolutely necessary and I normally ask the person I’ve called if it’s a good time to speak. Scheduling and priorities are important, we should make a point of telling folks that “now is not a good time, can I call you back later” – try it, you’ll be surprised how receptive folks are to this.

If you thought that some of this posting sounded like time management, you’d be right: I’ve read a handful of books on TM, perhaps it’s sinking in now!

Project Management

How much pressure is required to make somebody more productive?

1 Comment

Michael has written another great post here. I don’t want to steal his thunder, so please go read his post (it’s an excellent read), then read my thoughts below!

Earlier this year a good friend and colleague was discussing (with my boss) the idea of increasing workload and the pressure required to improve/increase productivity. Working out just how much more work an individual can cope with is difficult and is one that Michael covers in his post. Too much work and the individual goes in to shutdown mode, too little and they procrastinate.

Whilst I agree with increasing a person’s workload, it’s important to consider the unseen work they might be undertaking. For example, and I don’t wish to blow my own trumpet, I put in a lot of hours for my employer (more on this in a moment) and I put in a lot of voluntary hours writing/presenting for Scottish Developers, the Developers’ Group and Agile Scotland, amongst others.

I’ve recently seen my employer’s workload increase, particularly the amount of travel has increased. This has meant sacrifices elsewhere: writing takes time and inclination, without both, writer’s block is very common. After a working week involving a lot of travel and 6-8 hours of working time each day too, one doesn’t really feel up to firing up the laptop to start work on articles and presentations!

Earlier in this post I mentioned that I put in a lot of hours for my employer. I put the hours in just to get the job done: and I try my best to make sure it’s a “good job, well done” too. I’m sure that I procrastinate, who doesn’t? I’m sure that I sometimes take longer to complete a task than the next person, again who doesn’t? What I have noticed however, and this is a general observation, not specific to any organisation, is that there are folks out there who take a long time completing what should be a simple task. Of course, there are similar folks who can complete the same simple task in a much shorter time-scale than was ever expected.

Productivity comes through “getting on with it”, it comes with the realisation of “task completion”: the more tasks that an individual completes, the more productive they should become. Ultimately, the individual will set their own threshold. For productive individuals, this will be easy and should require no outside involvement, which, IMHO, is a bad thing: outsiders shouldn’t try and alter individuals thresholds unless the individual concerned is the worst kind of procrastinator, the kind who never finishes anything.

Project Management

Why Scrum Works

Scrum, the ethos of simplicity.

Last week I gave a presentation to the Developers’ Group and Scottish Developers user groups.

I spoke about the project mangement/control technique known as Scrum. The session ran for over an hour and some lively debate followed. Read more about it here.

Anyway, the slides and a sample backlog are now available here.

It’s worth noting that for the purposes of this session I split my product backlog in to four sprints. In reality, you probably don’t know the contents of subsequent sprints until after the last sprint has been completed. Agility. Flexibility. Simplicity. It’s all about the freedom to change the order in which requirements are turned in to working value/functionality.