Category Archives: PM#

PM#11 – Management By Shouting Loudest (MBSL)

26/2/2011 Craig Murphy 3 Comments

[Originally drafted in 2008, published 2011 with minor modifications]

Via http://mysite.verizon.net/charliez/murphy.htm

Swipple’s Rule of Order
He who shouts loudest has the floor.

He who does shout loudest and takes the floor, often fails to realise that there may well be other people who can’t or won’t shout louder. Thus we find ourselves in a position whereby other folks’ opinions are either not heard or become of secondary value: there is a huge lost opportunity. It’s a lost opportunity because those folks whose ideas and opinions that are not heard, may well be better than those offered by the people who shout the loudest. Shouting the loudest may also be referred to as Management By Shouting Loudest (MBSL).

Similarly, he who shouts loudest may believe that their contribution or their requirements should take priority over those contributions suggested by others. Where prioritisation is assumed, one needs to consider the knock-on effect – whenever something becomes your top priority, something has to give. A lack of warning or preparation on the part of others means we suddenly have an emergency to deal with. It’s also about respecting folks’ schedules – folks in IT don’t sit at our desks twiddling our thumbs waiting for your emergency to happen (a common misconception that affects the IT industry on a large scale).

If you do succumb to accepting a task from somebody who shouts the loudest, think about the impact it has on your current schedule. What is being sacrificed? What is going to take longer to complete? Apart from yourself, who are you letting down as a result of accepting the MBSL task?

It’s no wonder that “he who shouts loudest” is a very old trick and one that is still in use today. Watch out for it, try to curb its use by catching it early: try and coach the person doing the shouting into adopting a more democratic approach. Look out for lost opportunity moments, capture those, give them air time – you may be surprised how much innovation is lost by accepting the MBSL way.

In this series:
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#10 – The truth is best…admit it…

7/9/2005 Craig Murphy 5 Comments

Project managers aren’t interested in listening to or reading about all the excuses that you might use to explain why something hasn’t been done. Nor are they interested in watching you try and get off the hook by listening to or reading about who you believe is to blame for your failure to do something.

If you haven’t done something that the project requires of you, or if you have made a mistake, the best thing you can do is admit it. The truth is best. Don’t send e-mails citing reasons why something hasn’t been done. Don’t write e-mails professing your apparent innocence and attributing blame on somebody else – if you haven’t done something, or if you can’t do it, tell somebody, tell the project manager. Feeble excuses don’t bring projects in on time or on budget, honesty is the only helpful option.

We’d rather know that something hasn’t been done, or that you can’t do it, as early as is possible – it gives us the chance to consider our options and still stand a chance of bringing the project in on schedule and close to budget. If you provide us with a barrage of e-mails with content similar to the above (blame-mail), the project is likely to incur schedule and budget hits (time is money).

If you admit the failure honestly, early and without blame-mail, you will be respected for your decision. It helps you, it helps the project manager, it helps the project, it helps the business.

The truth is best…admit it…admit it early.

PM#, Project Management

PM#9 – Avoid duplication of effort

2/9/2005 Craig Murphy 4 Comments

Doing the same job once is optimal.

Doing the same job twice is criminal.

Doing the same job three times is just plain stupid (this happens, I’ve seen it)

Doing the same job four or more times is criminal and plain stupid (this happens too, really, it’s true)

Duplication of effort manifests itself in many ways, a few of which I’ll discuss here:

Procrastination.
We’re all guilty of this. Put simply, we look at our to-do list and we “hum and haw” about which item(s) we want to work on. Some items are too big, we feel that we’ve not got the time to do the item justice so we put it off. Other items are boring, so we focus in on the more exciting and less tedious items. In reality we should be focusing on the items that will add the most value to the “big picture” or the overall project. If you don’t think you procrastinate, try following the suggestions in the Touch it once topic below.
Two (or more) groups expecting the same information from the same source (often in a slightly different format).
This is a “duplication of effort smell”. Folks start seeing project-related data that is of some interest to them…they start to ask for reports based around that data without realising that reports actually take time to create, they fail to recognise that the report author has other things of greater importance to the project to work on. Similarly, if the underlying data changes, the report author has considerable round-tripping (going back’n’forth) in order to push the updated information out those who [claim] that they need it.
The wrong people being involved.
Hi-jacking of information is not uncommon and is one of the “duplication of effort smells”. A project can be making good progress, then all of a sudden, somebody starts taking an interest in parts of the project that really are outside of their skill-base. This is actually similar to 2 above whereby the wrong people sudden get involved by asking for reports/data in a format that suits them. They often join the party late, i.e. they did not realise that the data might have been important to them at the start of the project. If the wrong people are involved, it often manifests itself by virtue of the fact they have arrived on the scene after the scene of crime officer has been and gone, or by virtue of the fact they do not use the report/data correctly (or at all).
Failing to start it…finish it.
Similar to procrastinating, we often find ourselves revisiting an activity or task thus incurring the “start-up smell” whereby we have to spend time “getting back up to speed”. Interruptions are a key indicator that tasks will be started and returned to at least once prior to completion.

Touch it once
During a discussion about time management, a colleague pointed out a technique that appealed to me. How often do you pick up a document, look at it, procrastinate over it, then put it down again? You’d only be human if you agreed that you frequently pick documents up more than once! My colleague presented a well-known technique that catches this procrastination: each time you touch the document, you mark it with a red dot…the measles inducer. When you reach three red dots, you should agree with yourself that something has to be done with it. More about this common time management technique can be found here.

Of course, touching it more than once is a duplication of effort smell and the red dots will be the give-away…

The perils of the solution…
Obviously solving any duplication of effort requires that the duplication is identified. There are many reliable methods of doing this, not least a basic work-flow analysis. However, identification is the least important part of the solution. Once identified, removing the duplication enters into the realms of a political quagmire. The parties responsible for each part of the duplication will endeavour to prove that their duplicated process is the best one and that one that should be kept. They’ll also argue that their process is required for their day-to-day business, or that it is critical to the project or is just part of the fixtures and fittings (an unwritten policy or procedure if you prefer). This is your biggest problem, convincing those involved in the duplication to change their ways, to accept a single more optimal, more efficient way of achieving the same – a way that costs less, is completed quicker (early access to benefits, etc.) and generally makes the project more friendly and more approachable.

You may also encounter push-back when tackling item 2 above. Folks will cite “systems” as their need for the same data in different formats. “Our XYZ system needs project activities to be recorded in days”…whereas…”our ABC system requires project activities to be records in hours”. An easy conversion between hours and days may be possible, however in reality, different folks work a different number of hours per day. In such situations, where folks are perhaps being blinkered by the proximity of their problem and the need for the data in their format, where folks are unable to think out of the box, we must find a way of allowing them to take a step back from the problem itself. This will allow them to see the bigger picture, to understand the problem in context, to realise that they might need to change their processes in order to provide a better service now and in the future.

Whether you identify those involved in the duplication before or after you streamline the duplication down to a single activity, is up to you. In some instances it might be better to invite “the duplicators” into a [stand-up] meeting that can be used to determine the streamlined activity…this might win you friends and get you more buy-in. Either way, identification and removal of duplicated effort is paramount and should be embraced by all parties.

In this series:
#8 – Multi-tasking is evil
#7 – High workload means lower productivity…
#6 – You were right and I was wrong
#5 – Whose schedule is it anyway?
#4 – Start it…finish it
#3 – Use e-mail properly
#2 – Focus on the project
#1 – decision making

PM#, Project Management

PM#8 – Multi-tasking is evil

17/8/2005 Craig Murphy 2 Comments

“Nobody can do two things at the same time and do them well.”

Don Marquis

Clarke has often lamented about how multi-tasking is evil, something that was emphasised in #7 – High workload means lower productivity…

Humans aren’t multithreaded, therefore we can only do one thing at a time (this applies to men and women, please don’t be shocked or surprised).

Overlapping activities vs a three-course meal
Invariably, the more work that you pile on an individual or the more work that he or she accepts, you’ll find that individual attempting to multi-task under the premise that they believe they can do two or more things and do them well. Most of us struggle to cook a healthy meal, getting the timing right such that the meat, the vegetables and the potatoes are all ready at the same time eludes us. So why should we expect the same individual in the workplace to be able to manage three work basket items at the same time and with the same delivery date? Unless the three work basket items are trivial, we should endeavour to work with the individual and ensure that the three work basket items are scheduled such that there is little or no overlap.

Why do we find ourselves multi-tasking?
Multi-tasking, it seems, is forced upon us because there is a fear that employees will either take too long on a task or will complete it early and have nothing to do until the next task is issued. If you’ve got staff like that you should fire them and hire some staff who like challenges and who like endorphin rushes when they start something and finish it…at which point they’ll go off in search of the next challenge. Keeping an employee or developer busy seems to be fairly normal – we all moan about how much work we have to do…instead of moaning (or blogging as some might say), go and start a piece of work, progress it in small bite-sized chunks. Not all tasks need 2 hours, 2 days or 2 weeks to complete – those that do can be broken down into smaller more manageable tasks that are easier to swallow (read: easier to start). When you do break a larger task down, do be sure to follow each of the sub-tasks through to completion…and don’t lose sight of the parent task (i.e. don’t be distracted and lose focus!)

Respect the schedule
We find ourselves multi-tasking because other people don’t realise that we might have a schedule (a sequence of events/tasks that we’re trying to follow). Other folks will happily e-mail you, telephone you, walk up to you and [in the words of Scott Adam’s Dilbert] “expect you to drop whatever you’re doing and work on their problem”. Quite how you tell these folks that they are upsetting your carefully crafted schedule (even if it is written on the back of an envelope, whatever works for you…) is likely to be a personal thing and something that varies from organisation to organisation. Whatever you do, other folks have to understand that you are not sitting idly by your telephone or inbox waiting for them to contact you…you have work to do, you have a schedule, you have deliverables. Multi-tasking or task-switching will make you less productive which has a spiralling effect on the health of the project and your own health.

However, being seen to have a schedule and offering to fit their request in to your schedule is likely to win you some points too. Find out when these other folks need you to do their work by, then negotiate to fit it in: it’s very probable that with the thought that they’ve offloaded work onto you, the other folks will be happy with a negotiated date that suits you more than them…after all, you are saving them doing the work in the first place.

As soon as other folks realise that you’re working to a schedule and that they are part of that schedule, your multi-tasking or task-switching instances should reduce. Over time, those other folks will learn to approach you in less disruptive ways, e.g. via e-mail, knowing that you’ll “schedule it in and get back to them”…well, that’s the plan at least. I’ve enjoyed some success with this approach, it does depend upon the make-up of your team.

Pseduo-multi-tasking?
This might sound like I’m contradicting the purpose of this post, but it’s not, trust me. Despite heavy workloads, most of us are guilty of some degree of procrastination. We’ll delay or put off starting a task because…because it’s too big, because we don’t understand part of it, because it’ll take a long time to start and finish. Fine, either break it down into the previously mentioned smaller tasks or just start it. I’m using this approach to ensure blog posts are published: I simply start a blog post and save it drafts. Every so often I’ll spend a few minutes updating the blog post until it’s ready to be published. It’s easier to find a few minutes here and there than it is to find a few hours. Obviously this approach is only useful where tasks can be tackled in this fashion.

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#7 – High workload means lower productivity…

10/8/2005 Craig Murphy 1 Comment

My friends and colleagues over on the SellingAgile group were discussing productivity recently. Tony and Clarke were at the heart of the discussion, it went a little like this:

Tony made an excellent post, too long to quote here, but I particularly liked this:

In the age of interaction-centric systems, it’s all about speed. Forgo the false god of utilization. Concentrate on speed and concentrate capacity, so that those valuable software products and the mountain of moola that each of them can bring might arrive today rather than tomorrow.

To which Clarke asked:

Are you saying that if everyone is busy all the time then they will actually be a slower at doing things?

To which Tony responded:

Yes, Clarke, if we ensure that we have active projects enough to guarantee that every developer has project work available, then we _CAUSE_ the whole system of resources to work at approximately half its sustainable speed. Management teams worldwide are wasting approximately half of the capacity of their development teams and, consequently, half of their development payrolls.

It became clear that some folks believed productivity is low because we’re overloaded with work.

Basically, this boils down to the fact that software developers (amongst others) rely on creativity in order to do their jobs well. Without suitable periods of “down-time”, work simply moves from one task to the next with little regard for “can this be done any better?”

Tony then went on to make this remarkable statement:

Think of multiple marathon relay races. We have one team and many marathon relay races for the team to run. If we schedule the races so that one race must end before the next race can start, then our team doesn’t get to finish very many races per day or per week or per year. So we surely want the races to overlap. But for each of our runners we absolutely do not want his/her segments across races to overlap. That would force the runner to jump from track to track and race to race without handing any baton to a downstream teammate. So, we overlap the races, but we don’t overlap any one runner’s segments across races.

Today, due to our unfortunate and grossly inadequate understanding of interaction-centric systems, we schedule the STARTS of our races far too closely to each other. This guarantees that every one of our runners is always on some one track or another, running at least one race and usually several races simultaneously. Then we require our runners to make progress simultaneously on all their active races, by failing to prioritize the races. This forces each runner to hop from track to track and from race to race repeatedly, before the baton of any one race is transferred to the next teammate. This is multitasking in all its ugliness.

Clearly multitasking is absurd in the context of relay races. But it is no less absurd in the context of product development. Yet this absurd behavior is precisely what we cause when we strive to maximize utilization. The resulting lack of performance is a tragedy of our own making.

Whilst folks think that having a steady stream of work is good, it seems that we worry about a number of things:

that we won’t have time to complete the current task (and do it well)
that we won’t have time to complete the next task
this appears to be a recursive worry

So, my take on this discussion resulted in this:

Start something.
Focus on it using decent chunks of time.
Do it well.
Finish it.
Don’t allow yourself to be distracted by “what’s coming next”. Don’t flutter from one task to the next and back again.

Leaving an activity in an unfinished state will cause further distraction as your mind will play tricks with you, you’ll be worried about the unfinished tasks whilst you are working on current tasks. Break your tasks down into manageable chunks (task time average = 30 minutes), proceed to start each task and finish it, allow yourself some downtime (if you refer to it as slack, it’ll be consumed by the project, avoid using the word slack). Doing less work ~~should~~ will actually make you more productive.

PM#, Project Management

PM#6 – You were right and I was wrong

9/8/2005 Craig Murphy 2 Comments

If you make a mistake, I’d like to think you would be man enough to admit it.

The trouble is, and I’ve seen this in so many places, there are a lot of folks out there who seem to be unable to admit that they made a mistake. I’m sure that we’re all guilty of covering up a the odd faux pas here and there, but there are folks out there who take the cover up to new [stellar] levels. These stellar levels include such things as poor decisions or incorrect decisions (more here) and choices that have led to projects going off on a tangent for months on end all because of parochial approaches that prevent acceptance of the bigger picture (i.e. focusing on one small part of the project without understanding the project as a whole).

Saving face is not all that important, doing the right thing is. In a project-based environment, saving face for long periods is detrimental [to the project]. When driving, if you accidentally take a left instead of a right, you will endeavour to correct the mistake as soon as possible…you shrug your shoulders and get on with the course correction. Please take this analogy to your current and future projects: if you make a mistake, your cheeks go red, you blush, whatever, please raise your hand and announce your mistake. Team members will thank you for it, the project will run smoother and will stand “one more” chance of coming in on time and/or on budget.

Whatever you do, don’t try to ignore the mistake, cover it up or keep running with the mistake as if it were normality. And accept that team members might point out the mistake and ask you to do something about it: don’t fob them off with pithy excuses whilst you insist that you are right and they are wrong. Project rarely have “get out of jail free” cards, if you think you’ve got one please be aware that the card expires very very quickly after use: expect to be found out. Long running cover ups or long running changes in direction are catastrophic for the project and the team member morale. Do not think of yourself, think of the project and the team members (learn from what Derek Laud had to say about a lack of selfishness) – it’s not your project, it belongs to the team and the end users.

Don’t ever be afraid to say: “you were right and I was wrong”, it’s the best thing for you, the project and the team members. And say it as early as possible (mistakes and oversights are typically cheaper to fix earlier in a project).

PM#, Project Management

PM#5 – Whose schedule is it anyway?

31/7/2005 Craig Murphy 6 Comments

There was an interesting discussion entitled “is it just me?” over here at Scottish Developers. My reply is here. Anyway, it preempted this posting in some respects, but I’m going to carry on with this post regardless!

Customers and management never seem to believe the estimates developers give them…time and time again, developers provide an estimate of how long a project (or task) might take, e.g. 12 weeks, only to be told (by the customer/management) that it will take 6 weeks. There are many reasons for this sudden shortening of the schedule…many of which revolve around the fact that the customer/management have promised their upstream customer/management something (a software solution) by a given date. An unrealistic date at that.

Who is more qualified to make schedule decisions that relate to software development? Is it the person whose job it is to actually “cut the code” (the most important part of any software project, no code, no project), is it the person who actually does the job or is it the person who has promised a piece of software to their upper management by a certain date?

Despite any potential previous bad experiences, customers and management should learn to trust developers more, they are the most experienced resource management tool a software project will ever see. They have excellent gut reactions, they know when something is “do-able” or not. They can reliably tell you whether something requires 4 hours or 4 weeks to complete. They know their business, inside out.

So why is there such disrespect for developers and the work they do? Why do I hear lots of sob stories revolving around late delivery, “he said it would take 4 days, it took 12 days, his estimates are rubbish”?

The simple answer is this: unless the part of the schedule that a developer is working toward actually belongs to him, realistically speaking, the developer knows he’ll not be able to meet the schedule but will carry on regardless. He has nothing vested in an arbitrary schedule that does not give him enough time to to his job properly. True, the developers will probably bust-a-gut trying to bring the project in on time, however as we know, invariably they’ll fail. But it’s not their fault. It’s the fault of the person who gave them the wildly inaccurate schedule in the first place.

Even if the schedule was remotely accurate and did have input from the developers, other folks exhibit a disturbing lack of respect for the developer and the schedule. A schedule can often be agreed provided that all or some tasks are distraction-free: this is easy to agree at the outset, but rarely happens during the project execution. Similarly, a fully-committed developer has no “resource gap” or free-time, there is no “contingency” in most projects. Therefore, you cannot duly expect to either e-mail or walk up to a developer and ask them to take on other tasks (for other projects) that aren’t part of the schedule…and since developers (and a lot of other good folks) find saying “no” difficult, they can often be [bullied] into saying “yes” to more work that will invariably knock the previously agreed schedule out. The trick here is not to offer developers other work – no matter how important it is to you (your top priority work isn’t going to be the developers top priority, he’s busy focusing on the project.)

Getting schedule buy-in from the developers is key – give developers the chance to form and shape their own schedule, let them break tasks up into smaller more manageable chunks that can be delivered over shorter periods of time, e.g. every 30 days or less. Don’t force them to buy-in to a [rolling] project plan that spans 6+ months – the speed at which the software business moves at, 6 months is far to far away: focus on what can be achieved now rather than later. Developers also need an endorphin hit every so often (cited as being every 2 weeks) – they get endorphin hits by starting and finishing a task, by seeing a piece of their code [go into production] in front of a user/customer or by visibly moving the project forward in some respect.

Analogy
When you last had you car serviced, you probably gave it to the garage for a whole day. I don’t hear about folks telling the folks who work in garages: “You need my car all day? No, you can have it for 3 hours. Can you get everything that needs doing done in 3 hours?” I’d like to see the state of your car once you get it back…may be not today, but in a few weeks time when you thought all that work had been done…

Example
I have a standalone application – a single .exe that runs on a per-machine basis. A client has requested that we “get it to work over the network”. For us, this is a big job, it requires changes to the backend database to allow the introduction of a user column (at least), transaction support, improved backup/restore, etc. To the client, networking an application is the simple matter of adding a login box at the start of the application. Since that’s all the client ultimately gets to see…”how can that possibly take N weeks to write?!” Perception and explanation are key. As developers we must learn to stand up for ourselves and learn to say “no” to unrealistic schedules: whoever is asking you to commit to such a schedule doesn’t understand how their car works, yet you won’t find them telling the garage to cut their schedule in half…unless they are themselves a mechanical engineer (versus a fitter), in which case they would need to be experienced software engineers in order to discuss schedules with you!

Need to cut the schedule? Well, why not cut the feature set?
If you have a pressing need to cut the schedule, at least negotiate with the developers over the feature-set that your hoping they’ll implement in the shorter time-frame. We know that “80% of a product’s value comes from 20% of its features” (originally from here), surely you can afford to cut the number of features in order to cut the schedule? Of course, now we’re in the realms of controlling the four success variables (cost, time, scope, and quality).

four variables

In the first instance the customer is allowed to select values for any three of these variables. The development team will then choose the value for the remaining forth variable. Ultimately, between the customer and development team there will be a series of compromises and trade-offs resulting in an adjusted set of values, or even trading of variables!

There are interactions between the variables. For example, increasing the time can allow for an increase in quality and/or an increase in scope. Another example might be a reduction in scope: it is possible to deliver earlier (less time) or cheaper (less cost) or possibly with more quality.

It is worth noting that the relationship between the four variables is a complicated one – it is not possible to reduce the time variable simply by increasing the cost variable. Nor is it possible to increase the cost expecting an increase in quality.

Crazy Schedules
Schedule pressure often sees shortcuts (or what are perceived as shortcuts) being taken. Instead of well-structured, reliable object-oriented code, being ~~cut~~ produced, prototypes are built as proof of concept…a little cut’n’paste then follows, prototype code suddenly becomes production code but only after crazy amounts of testing and re-work. It’s a spiral that requires a step back and a re-write to get out of, and may be more than one re-write at that. Crazy schedules will cost you considerable amounts of time and money downstream, they’ll also cost you the respect of your developers too.

Scott Berkun wrote an excellent book, The Art of Project Management, reviewed here, where he cites an example: your client in on the operating theatre table, the brain surgeon tells him that the operation he requires will take 12 hours…you won’t find your client turning to the surgeon and saying “no, you have 6 hours”…This just wouldn’t happen, I rest my case: if programmers or developers tell you something will take 12 hours, give them 12 hours (or more if you’re generous), it’ll protect your reputation, they’ll respect you for it and it’ll give your project more chance of success.

<br />

PM#, Project Management

PM#4 – Start it…finish it

27/7/2005 Craig Murphy 8 Comments

As Dr.Neil Roodyn says, keep your task duration/time down to a 30 minute average (which means your tasks can be anything from 5 minutes to 120 minutes in length, it’s the average we’re interested in).

Just as important as the task duration, is the need to ensure that a task can be both started and finished. Long-running tasks do nothing for a person’s (read: developer) motivation and desire to focus on the project in hand. There’s little point asking a person to do any more if their in-basket/work-basket is already overloaded with tasks that have been started, but not finished.

I call this role Starter-Finisher, Dr. Meredith Belbin calls it Completer-Finisher. Either way, the job needs doing; starting can be easy, which is perhaps why Belbin believes the role should focus towards the end of the task, i.e. the finish or completion.

Completed/Finished tasks elicit feedback, feedback drives quality, quality drives customer satisfaction and customer satisfaction drives profit.

So, the simple statement that this post is trying to make: if you start something, finish it. Don’t let anybody distract you whilst you are completing (working on) the task, try and set aside a suitable chunk of time that is free from interruptions. Remember, the shorter the duration [of the task] the more accurate your estimate of time to complete it going to be. If you have to, break longer tasks, e.g. longer than 2 hours, into smaller more manageable tasks. Of course, you may need to remind folks that it is your schedule, not theirs, and that contrary to common belief you won’t drop everything to work on their problem.

PM#, Project Management

PM#3 – Use e-mail properly

14/7/2005 Craig Murphy 4 Comments

E-mail can be a hinderance for three reasons:

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.
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!)
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).

PM#, Project Management

PM#2 – Focus on the project

10/7/2005 Craig Murphy 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!):

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.
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.
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!
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.
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.
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).
Too much travel.

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.

PM#, Project Management

PM#1 – decision making

14/6/2005 Craig Murphy 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.

The Social Programmer

Category Archives: PM#

PM#11 – Management By Shouting Loudest (MBSL)

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

Craig Murphy: author, blogger, community evangelist, developer, speaker, runner