I’ve spent the last two three weeks reading through Scott Berkun‘s first book, The Art of Project Management.
It’s an excellent read, I’ve reviewed it for the folks over at Scottish Developers.
If you would like me to review your book, either like this or prior to publishing, drop me an e-mail via the address found at the bottom of CraigMurphy.com.
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 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:
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
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.
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.
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.
Our first visit to the Bluebell Railway was on Friday 13th May. Unluckily, it was a dreech (wet, miserable) day, a trip on a steam train was thoroughly unappealing. As a result, we found ourselves wandering around the shopping Mecca that Brighton isn’t (my wife can find shops anywhere, thankfully the rain slows her down!) I’m sure Brighton has its attractions and it’s probably a lovely place to visit when the weather is good. But, since the weather wasn’t nice, I didn’t think much of the fact we were out and about in a wet town that was unknown to me. Why couldn’t we just go to the pub, at least until the weather cleared? It was a Pizza Hut lunch, carefully discovered by my wife, despite my attempts to thwart her finding it…sometimes the stomach can be a marvelous motivator when it comes to walking long distances! C’est la vie!
Anyway, we returned to the Bluebell Railway on Sunday 15th May to find a re-enactment of our boys returning from The Second World War. The sun was shining, the jazz band were playing period tunes at just the right volume and all around us were guests wearing period outfits. The military, of course, took full control of the situation, ration books were issued, travel tickets and particulars were checked. We, the general public, became immersed in a drama that took us back to 1945, we became actors, we (all) helped make the day. Except for those of us with digital cameras…we took our 21st century technology back in time to capture the moment. The re-enactment made the day.
The Bluebell Railway offers you the chance to ride on authentic steam trains running on a timetabled schedule. Departing from Sheffield Park, briefly stopping at Horsted Keynes before terminating at Kingscote. There are some good pictures here.
The Bluebell Railway is definitely worth visiting if you are looking for something to do whilst here. I can strongly recommend visiting during a re-enactment…check their web-site for more details. Further information can be found here.
Actually, thinking back to the day itself, there was one thing missing: beer. I couldn’t find beer anywhere!
Here are a few photographs, trimmed for posting here…it seems that even text messaging was popular back then, as one of the photographs below demonstrates!
There are more photographs of the Bluebell Railway here.
Michael Taylor has some great pictures over here.
I’m pleased to announce that my review of ADO.NET and System.Xml v 2.0: The Beta Version has made it from its original publisher, The Developers Group, to daveandal.net…and beyond.
You are free to publish this review on your web-site subject to the original author and original publisher being acknowledged and referred to.
Learn more about the book and read my review via this link:
Mark has some great BlogCast advice that links to the BlogCast repository. (Mark’s post is also available here.)
If you feel the need to add sound and movie clips to your blog posts, or simply wish to use small movie clips to demonstrate something or educate folks, Mark’s advice and links should prove very useful. I’ve created a small BlogCast myself and can confirm that it’s really easy to do.
Bandwidth permitting, watch out for BlogCasts on this site, “real soon now” as they say 🙂
Further to my earlier post, I am pleased to announce that the session list and agenda have now been finalised.
If you haven’t already signed up (why not?) please visit the event’s dedicated web-site.
Attend DeveloperDeveloperDeveloper to learn more about Scrum, Test-Driven Development (TDD), Refactoring, Web Services in .NET 2.0, ADO.NET 2.0, .NET Custom Attributes, Web-Site Security, ClickOnce Deployment, FxCop, Developing for the Compact Framework, ASP.NET 2.0, Patterns of Data Access in .NET, Selling yourself as a developer, SQL Server 2005 CLR and the Mono project.
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?
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!
Yesterday I had the pleasure of securing a brand new Dell PC that belonged to a work colleague.
The said PC came rather well protected, McAfee’s internet security suite was installed and appeared to be working. It would continue to work until July, when the 3 month trial expired. What then? Well, most users cringe when their PC asks them for money, so it’s very likely that the trial will be allowed to expire gracefully. The sudden appearance of spyware, etc. would be less than graceful.
So, amongst other things, I removed the McAfee trial software and replaced it with the free edition of ZoneAlarm and Grisoft’s AVG anti-virus.
I must say, it’s nice to see ZoneAlarm at work. I have a firewall in my Netgear router and find myself shielded from the automated attacks that are so popular. Over the course of the 30-minute securing exercise, we watched no less than 200 inbound intrusion attempts…all nicely blocked by ZoneAlarm.
Incidentally, when ZoneAlarm announces that an upgrade is available, my advice is this:
Watch out for a forthcoming article/post covering security software in more depth!
14th May 2005 – DeveloperDeveloperDeveloper!
In my earlier post I mentioned Microsoft’s DeveloperDeveloperDeveloper! day being held in Thames Valley Park, Reading, UK on the 14th of May 2005!
I’m working on two sessions for Microsoft’s DeveloperDeveloperDeveloper! . I’ll be delivering two sessions: An Introduction to Test-Driven Development and Refactoring in Visual Studio 2005.
Amongst many others, Phil, has written a good piece summing up what’s going on! Whereas Microsoft’s Mike Pelton has gone into code to explain the day!
Registration is recommended!
Recommended Audience: Developer.
For the first time ever in the UK, Microsoft is hosting a unique event for Developers to learn, share and hear from other Developers – NO Microsoft speakers will present. Held on a Saturday, DeveloperDeveloperDeveloper is designed to be an informal day; the agenda will be determined by the developer community. You will have the opportunity to see new faces present in a relaxed atmosphere. Activities will include presentations on a wide range of topics (see suggestions below), a networking area and fun zone.
• Preparing for ASP.NET 2.0
• .NET Debugging Facilities
• Patterns of Data Access in .NET
• An Overview Of ClickOnce Deployment
• What’s New In Internationalization In .NET 2.0?
• Unit Testing Using Visual Studio 2005 Team Test
• Introduction To FxCop And Writing Custom Rules
• Refactoring Using Visual Studio 2005
• An Introduction to Test-Driven Development (TDD)
• Developing for the Compact Framework with C#
• Custom Attributes in .NET
• Useful Free .NET Tools
• SQL Server Finding and Resolving Performance Problems
All this is FREE and lunch and coffees will also be thrown in.