All posts by Craig Murphy

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.

Developer Events, General

TechEd 2005 – E-mail or blog?

1 Comment

A couple of years ago we were all happy exchanging e-mail addresses…this year, it seems that all I did was exchange blog addresses.

Why the sudden interest in blogs? My first few thoughts on this are: Blogs open us up to our readership, they provide a means of working out how somebody ticks. Couple this with the fact I can publish information about “a topic” and push it out to the world…no longer do I have to rely on somebody sending me an e-mail to which I then have to reply (actually, it’s easy to rely on somebody sending me an e-mail, the bits that’s hard is for the sender: I might take an age to reply.) Blogs alleviate this “waiting game” – if the information is published via a blog, it’s there and waiting for others to read. I find this rather interesting, so I’ll blog some more about this topic as soon as I have some content.

Here are the blogs of a few of the folks I met:

Korby Parnell. Korby’s got a lot of good stuff to say, especially about GotDotNet – thanks for the t-shirt and badge, I’ll wear ’em at the next .net event! Korby, Adrian Bateman, Maarten Visser (more here) and I had a late lunch followed by a very lengthy chat on Friday – we were discussing taxonomies, specialisation, association, adding meaning to searches, etc. The chat went on through the afternoon until we reached a point that we all had to split and head our separate ways. Watch this space…there’s a huge work in progress here, if only we can find it and specify it.

Oh, and if you take a look at Korby’s blogroll, you should find that it follows my “separation theory”, as noted here.

Betsy Aoki. I missed Betsy at a recent UK Community Leaders LiveMeeting, it was good to catch her in a couple of sessions and to chat in between times. I’ll be blogging about Besty’s TechEd 2005 sessions later this week – I have written notes and drafts in place already. There was, just to give you a taster, much talk of Robert Scoble (good talk I hasten to add, just in case Robert is reading this! Hey, let me dream about something!)

Speaking of the Scobleizer…look what he just posted. Lordy!

Eileen Brown. Eileen has a really cool picture of herself on her blog: I was lucky enough to learn about the history behind the photograph. My primary reason for pinging Eileen was to chat about blogcasts…Eileen and John ran a great session for MVPs last month.

Benjamin Mitchell. I sat in on Benjamin’s WSE 3.0 session, which, despite the video recorder not functioning at the start, went very well. Obviously the faulty VCR wasn’t Benjamin’s fault and he did a good job of padding until a new one arrived! Benjamin was at my end of the table for dinner on Monday night so we chatted about “how we get things done”. Benjamin and I seem to share a common thread when it comes to “how much work do we take on” and “how much free work do we take on”. There aren’t enough hours in the day… Anyway, Benjamin, Peter McMahon, Durgaprasad Gorti Adrian and I manned the “Ask The Experts” stand for many hours on and off. From what I saw, Benjamin has the “Scott Hanselman desktop“!

Mat Stephen. Amazingly, when I got back to my desk and tried to add Mat’s blog to my aggregator it told me it was already there. True enough, it was mentioned during the aforementioned blogcast session…I even had it written down in my notes! Mat’s some guy, I met him in the flesh on the Thursday of TechEd, then on the Friday we shared the same coach to the airport. Whilst at the airport we knocked back 2 * 1.5L pitchers of lager! We were also joined by three guys from Ireland…the time at the airport just flew by!

Anyway, that’s TechEd 2005 over, I’ve still got seven or eight posts about it to finish…tomorrow (Monday) I go back to my day job, so it might be later next week before they see the light of day.

In the words of Betsy Aoki, when asked about Microsoft’s policy on blogging (there isn’t one, in case you were wondering – isn’t it amazing how some of the best work is done without a “policy” in place?): “code smart, blog smart”

TDD

When Tests Get Hard

I attended Charlie Poole’s When Tests Get Hard session.

The first thing that Charlie said summed XP up for me: “lots of little bits that I’d being doing, but brought together”

Why is testing/TDD hard? A quick poll of the attendees revealed

  1. no obvious programming interface
  2. set up time too great, especially for databases
  3. code in containers or managed by containers can prove difficult to work with
  4. “Graphical User Interfaces (GUIs) either look good or they don’t”, another fine quote from Alan!

Charlie followed it up with: testing connected sets of objects is hard because:

  1. tests become dependent upon one another
  2. objects have to be put into a known state
  3. it’s hard to figure out what failed

We went on to look at why GUI testing is hard.

GUIs are hard to test because there is tight coupling to other parts of the application, including the business logic. The solution to this is to separate the business logic from the UI, to use interfaces to permit substitution and factories to create business objects. This ran into an interesting discussion regarding the use of interfaces: some folks have argued that using interfaces isn’t the simplest and most expressive “thing”. Charlie believes that they are, on the grounds that they make it clear that a class has a capability. A similar discussion can be found here.

GUIs are hard to test because there is one large program handling all user interaction. Charlie’s recommendations revolved around using separate classes for UI logic and for validation. He also recommended the creation of smart controls (NUnit’s status bar being an example of such a thing – if you have NUnit installed, take a look here: C:\Program Files\NUnit 2.2\src\uikit). The key takeaway from this point was that the forms know too much about the objects that are dropped on them.

GUIs are hard to test because the design is driven by the IDE. Today’s modern IDEs will let you create a form, drop a button on it, double click on the button and write code for the button click. Granted, if you are doing the simplest thing, this is the right place for code, but in the long term it’s the wrong place for code (sure, you’d refactor it out, right?) We should resist the temptation to insert code into a UI just because the UI makes it easy. We should split code into two parts, presentation and behaviour (the use of partial classes and inheritance can help with this). Charlie recommend that we all read or re-read Mike Feather’s The Humble Dialog Box.

GUIs are hard to test because of technical issues of the platform. Charlie reiterated the need to be clear about what testing is needed, i.e. don’t test the platform (except to learn how the platform can help you with your testing), or put other way “don’t test other people’s stuff”

I liked Charlie’s “The Hardness Paradox” which basically stated that if something that is hard to test, it has to be a good thing. This will force us to look more deeply at how are applications are designed, with a view to making them easier to test. Humoursly, we compared this to a bang on the head – were it not for the fact that it hurts, we might keep doing it! Why should we shy away from difficult activities? We’ve cracked TDD for [elementary] classes, now we’re moving on to the next stage: testing the UI, the database, the web service, etc.

Quote for the day:

“If you don’t talk to the customer, the details don’t come up” – Charlie Poole, Edinburgh, 30th June 2005

Lastly, I also had the luxury of joining Charlie, Clarke, Barry and Peter for dinner (Colin joined in but didn’t eat!)

(Oh, and NUnit 2.4 is under development! Can’t wait!)

.net

Excel Interop – killing Excel.exe

42 Comments

This posting over at ScottishDevelopers got me thinking, especially since I’ve used Excel and Word from a number of Delphi applications over the last eight years. I have come across this problem in the past (Win32), so I thought it should be fairly easy to chase.

After a bit of research, The Code Project suggested that the Excel process be killed off through code:

Process[] pProcess; 
pProcess = System.Diagnostics.Process.GetProcessesByName("Excel");
pProcess[0].Kill();

Well, that would work, but it might kill off the wrong instance, or kill off the user’s precious ‘expenses’ spreadsheet instead of the one we created.

To help me trace the problem, I used the following code:

using System.Diagnostics;
using System.Runtime.InteropServices;

Excel.Application	excelApp = null;
Excel.Workbook	excelWorkbook = null;
Excel.Sheets	excelSheets = null;
Excel.Worksheet	excelWorksheet = null;
Excel.Workbooks	excelWorkbooks = null;

private void button3_Click(object sender, System.EventArgs e)
{
  excelApp                 = new Excel.ApplicationClass();
  excelApp.Visible  = true;
  excelWorkbooks   = excelApp.Workbooks;
  excelWorkbook = excelWorkbooks.Add(System.Reflection.Missing.Value);
  excelSheets = excelWorkbook.Worksheets;
  excelWorksheet = (Excel.Worksheet)   excelSheets.get_Item(1);
  excelWorksheet.Cells[1,1] = "42";
}

private void button4_Click(object sender, System.EventArgs e)
{
  excelWorkbook.Close (false, System.Reflection.Missing.Value,System.Reflection.Missing.Value) ; 

  excelWorkbooks.Close();
  excelApp.Quit();

  Marshal.ReleaseComObject(excelWorksheet);
  Marshal.ReleaseComObject(excelSheets);
  Marshal.ReleaseComObject(excelWorkbooks);
  Marshal.ReleaseComObject(excelWorkbook);
  Marshal.ReleaseComObject(excelApp);

  excelWorksheet = null;
  excelSheets = null;
  excelWorkbooks = null;
  excelWorkbook = null;
  excelApp = null;

  GC.GetTotalMemory(false);
  GC.Collect();
  GC.WaitForPendingFinalizers();
  GC.Collect();
  GC.GetTotalMemory(true);
}

This code creates an Excel application, populates it, then lets us close it. Invoking the button3 code creates it, button4 removes it.

Now, without the calls to the garbage collector, excel.exe hung around if the code behind button3, button4, button3, button4 is invoked.

In the short-term, I would suggest adding the additional calls to the garbage collector (although, and this confirms it, memory reclamation is not guaranteed). It’s time to read up on the garbage collector and COM Interop.

I used Visual Studio 2003 and Office 2003 to test this.

Technorati Tags: , , ,

General

Yet another easyJet flight

Isn’t it amazing how fate throws people together and from that into conversation?

Today, I found myself standing in front of the flight departure monitors at Gatwick airport (I had actually managed to drop my bottle of fizzy drink and was waiting on the cleaning bloke to mop it up…which he did and then left a yellow sign with a slippery surface logo on it…)

Anyway, I digress: a gentleman walked up to me and asked “Do you know where gate 18 is?” Part of me just wanted to say “yes”, but that would have been rude, albeit somewhat French/Parisien in its humour content (Sorry Alex!). But, before I could tell him that it was “over there, follow the big yellow signs”, he walked off…leaving me in eye contact with another gentleman who saw and heard the whole thing happen! Some humour about the situation followed…and we exchanged the usual pleasantries that one does with fellow airline passengers.

As it happens we ended up walking down to gate, briefly chatting on the way. Gate 10 wasn’t far away, it’s marked as a 10-15 minute walk I think, but it really only takes 5-6 minutes. We arrived at gate 10, along with a few others, only to be told that the Edinburgh flight wasn’t departing from gate 10, the Shannon flight was. Of course, the lady on the security desk was positive (and nice about it too) and made a telephone call on our behalf. Long story, cut short, we were departing from gate 12 instead. Now, being a frequent flyer, and one who listens to the safety briefing at the start of each flight (!), I figured that there was a delay. The time it would take us to get from gate 10 to gate 12 was roughly 10 minutes, more if you were a member of the original 10-15 minute fraternity…this would buy the airline some time! Now, easyJet have been very good, flights have been on time, etc. so neither of us were particularly worried about the faffing about.

Anyway, it turns out that this gentleman with whom I exchanged plesantaries owns and publishes a number of magazines: Spain Magazine and a couple of others (I know the names, but can’t find a web-site just yet). And he’s an actor: remember the parrot in the Scotch (now 3M) TV commercial? He did the yawn…and yes, apparently parrots don’t yawn, but that’s showbiz!

We landed on time at 2025…20 minutes into the flight the first officer announced that they’d made a couple of “left turns” and shaved 10 minutes off the delay…amazing 🙂

Oh, and Rt Hon the Lord Steel of Aikwood KT KBE DL was only a couple of rows behind us…sadly the first things that came to my mind and that of my travelling companion was the Spitting Image sketch where the two Davids (Owen and Steel) discussed the merger of their two parties (Social Democratic Party and the Liberal Party), to form the Lib Dems. The name change change wasn’t much for David Owen, but for David Steel’s party, it was! Anyway, it was funny at the time 🙂

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.

.net

Three * Virtual PC WinXP SP2 images created…

That’s me just finished creating a clean VirtualPC 2004 image with Windows XP SP2 installed.

I made a few copies, mostly all for use with products that are still in beta.

I’m only allowed to tell you about one product that I’ll be looking at and that’s Microsoft Visual Studio 2005.

Expect to see more posts as I spend more time living inside the Visual Studio IDE.

Incidentally, those generous folks over at Scottish Developers have some Visual Studio 2005 beta 2 boxed DVDs to give away, all you need do is attend a meeting or day conference (or if you’re lucky, speak to Craig nicely and he might post one out to you! You must be a signed up member of Scottish Developers though!)