ShowUsYour<Blog> : goals2004_ProjectManagement

Tips for effective communication

digory — Tue, 07 Dec 2004 07:31:00 GMT

Communication is a really inefficient activity and that's because it takes a lot of effort to do it well. This can also be exacerbated when in an environment with mixed cultures where participants may find the "listening" part of communicating a greater burden. Additionally, there are environmental modifiers that can affect the likelihood of having good communication such as: noisy environment, people who are tired or irritated, unsuitable venue, unsuitable timing, etc. Here's some tips that I have for increasing the likelihood of having a successful session of communication&

Find a neutral venue to carry out your discussions. Don't invite people into an area where there are likely to be distractions while communicating. I see this a lot with programmers who are supposed to be showing a peer how a piece of code is written and are constantly disrupted by Instant Messenger, Email or Telephone calls. If that scenario arises then I would strongly advise the developer to consider pulling the network cable from the back of their machine until they have finished communicating.

Before you begin your communications, clearly identify your objectives and take the time to summarize them to all other parties involved in the session. This is easily done by adding a bullet-point listing of objectives to a Meeting Request when sending it out - one of my pet peeves is receiving Meeting Requests which have an ambiguous subject line and no details outlining what it is that we are meeting for. At the end of the communication session - and, optionally at regular intervals during it - have a way to confirm that all parties have the same understanding.

After the communication session, have some way of checking back at regular intervals to ensure that what you have communicated is progressing as expected and, if not, take the time to re-communicate to ensure a good outcome.

Remember that the most important part of communication is listening. I read in a book last week that, if you want to be thought of as a great communicator then, all you have to do is to be good at listening!

Some golden rules to adhere by when thinking about features

digory — Wed, 03 Nov 2004 21:09:00 GMT

When we started doing a spec for ProjectDistributor Justin and I had some long chats about what features we wanted in and how they would be implemented. In fact, there were dozens of features that we discussed and, as we progressed we found that we needed a better methodology for quickly deciding whether features would be winners or losers. Additionally, we needed a better way to describe new features to one another so that we didn't waste cycles trying to understand what the other person was trying to say.

Justin quickly decided that anything we planned on adding or any new derivations, we should bounce these questions off:

What problem are we trying to solve (or innovation we are trying to make)?
How do we solve that problem?
What are some existing systems that solve the same problem in the same or different ways?
How is our system different from previous systems and what innovation are we adding?

We've found that this allows us to trade the ideas back and forth in an idea oriented way while allowing us to show any innovations in a problem solving way.

We've now decided - based on our success with them - to add these to ProjectDistributor. Soon, when adding projects, you will be offered the choice to answer each of these questions. This will allow people who are viewing your project to quickly gain a better understanding of why your tool rocks!

You don't need to have a deathmarch

digory — Wed, 27 Oct 2004 20:54:00 GMT

When creating project plans make sure that you define some interim milestones for the development phase. Interim milestones allow the development team to see measurable progress and provide key stakeholders with visibility about the progress of the project. Interim deliverables are also used to keep bottlenecks to a minimum and to reduce complexity when it comes to things such as testing and regression testing.

Recently I've seen a couple of projects become unstable through a lack of clearly defined interim deliverables.

In his presentation titled: "21 rules of thumb for shipping Great Software on time", Jim McCarthy talks about how an application is like a big bowl of jelly and how it is important to get to a known point and stay there. Getting to a known state allows the jelly to stop wobbling and again gives everybody with a clearer vision of measurable progress. The projects that I've seen go pear shaped were being developed in a fashion whereby it was not possible to get to a known state until the end of the project.

Recently, on one very recent project (which had a particularly low morale and was showing clear signs of being a Colonel Kurtz project) I was able to turn momentum within days by simply laying out some important interim milestones and hitting them early. These deliverables were designed to get important features to a "complete" stage and into test quickly which had a positive knock-on effect of restarting the communication between stakeholders as feedback trickled back from test into dev and up the chain of command. Everybody was energized and the juggernaut lurched forward; momentum is good.

Last word... interim milestones should mark important peaks. Don't set interim milestones around trivial marks.

The Colonel Kurtz Project

digory — Tue, 26 Oct 2004 11:37:00 GMT

Patricks Cooney, theorizes over a new project management orthodoxy...http://www.patrickcooney.com/weblog.aspx?i=61

How do we spot Kurtz projects? Try the following:

Scanty information: Nobody is saying anything, documentation is non-existent or irrelevant, ship dates are not seriously discussed
Messianic leader, whispers of insanity
Total collapse in the chain of command
The project team has 'gone up the river', and nobody knows when they are coming back

Taskpath

digory — Fri, 22 Oct 2004 05:49:00 GMT

At an interview the other day I was asked to describe what type of person I am. After a brief pause for thought I replied that I'm a task-oriented person. It's true; I am. I'm sure that that's why I love projects so much - you jump on a project, execute a series of tasks and then you are at the end.

After the meeting I walked away and (as you do) started to think more about a task. That led me to also think about some of the projects that I've been on and evaluating the various experiences that I've had. Some good, some bad, some lost in time.

So, what makes a project enjoyable and how can you be someone who manages enjoyble projects?

Every task shares a common attribute - and by inference this bubbles up to projects - and that is that they all have a path. No matter how long or short the task is, it has a beginning and an end and, inbetween is a path. The path can be straight, bumpy, windy, narrow or wide. The path will contain learnings, experiences and exchanges. And the path can be enjoyed, suffered or resisted.

When I'm planning a project and mapping out the tasks I take great delight in identifying some of those paths too!