Resource Center

Collaborative project management - How to start collaborating Author: Chris Vandersluis © 2000 Chris Vandersluis Printed in PM Times

So, you've been following along with our series on implementing collaborative project management and you've now decided to take the plunge. After all, it sounds good. Having the team collaborating on their projects is better than not collaborating right?

Well, yes - maybe.

Change causes upset. It's a truism. Virtually any change in the status quo, no matter how fabulous the impact in the long term or even in the short term, will generate upset from the people who are not used to doing it that way. You don't think so? Try changing the least significant structure in your office, say a telephone message pad, to something different and watch what happens. Humans are creatures of habit and once they're in the habit of doing something, you may find them very reluctant to change.

That being said, if you've decided to implement collaborative project management practices, you've no doubt figured out that the benefits of changing your process are worth a little sweat and tears. There is, however, another dynamic to consider when implementing such a structure.

The types of people who become project managers are often independent, free-thinking results-producing types of people. These types of people are, unfortunately, not ideal collaborators. They may be an element of reluctance from such people to commit to a structure where they must share information.

Discouraged? Don't be. For many different organizations there are tremendous potential benefits in efficiency to be had by implementing a collaborative process. I point out these pitfalls because over the years, I've seen too many failed implementations of a new project management process due to a poorly thought out deployment plan.

Those same results-producers don't always consider the human elements to changing a culture and to be sure, if you're moving from a non-collaborative to a collaborative process for managing projects, you're in for a big culture change.

As you plan your deployment, it's worthwhile starting by outlining all the elements of collaboration that are appropriate for your own organization. Here are a few examples:

• How are project team members informed of work to be done
• How are team members informed of key information on the project as it is updated?
• What is the change process for changing tasks and how is it communicated to the workers involved?
• How to workers inform the project manager of changes that must be organized because of something found at the task level?
• How does the project manager inform the client and/or management of project status?
• How do team members communicate with each other on work they must do together?
• Do team members require instant access to be able to communicate with each other? If so, how disruptive is this to workers' productivity?
• How do line managers manage inter-project resource conflicts and how are the results of this process communicated to the people involved?
• How do workers update the progress they've made on tasks they're working on?

It's not a comprehensive list of course, but you begin to get the idea. Once you've had a few facilitated meetings with the people involved in the project management process, you can start to prioritize these functions in order of they're impact on the productivity of the organization as a whole.

Now we come to the crux of the matter. There are two schools of thought on how to implement a significant change in culture in an organization. I call them the "Phased-In Approach" and the "Big Bang" theory. Many companies often attempt the Big Bang theory first then move to a Phased-In Approach.

Big Bang works like this. First, you identify everything you want to change, then you spend some time (Ok, a lot of time) choosing or writing software that will do everything you want, then on a given day, you change 100% of all terminals simultaneously and demand that everyone move over to the new process. There are pluses and minuses to such a plan. First of all, it's going to take some time and not just a little. While you're inventing the perfect process in a laboratory somewhere, no one will be getting any of the benefits you're hoping for. The good part is that the chances are that, if you are successful, you end up implementing more of the process than otherwise. The bad news is, that these types of deployments are often costly and unsuccessful.

This bring us to my favorite (I'm sure you guessed that already) deployment plan and that's the Phased-In Approach. With this method, you identify the most significant elements of the total process and begin by implementing them slowly. The down-side of this approach is that there's a good possibility that over time you will never end up implementing 100% of the originally planned process. However, the good side of this approach is multi-faceted:

• First of all, you can start getting benefits out of the process as soon as the first function is active.
• Next, you can fine-tune your process with experience from the field as you begin to implement it.
• It's also likely that you'll get an easier buy-in from both the end-users and management when you've only got to convince them of the first few functions you want to implement.
• The costs are almost certainly lower to get the process started.
• The disruption to the organization is minimized as it is spread over a longer period.

So, do you need collaborative project management software in order to accomplish all this? Yes, probably. But, you almost certainly don't need new software in order to implement some of it and that's significant.

A change in culture shouldn't be based on just having selected a new tool. It's like saying we're going to do plumbing today even though our problem is a broken light switch because the only tool available at the shop is a pipe wrench.

If you map out the process you'd like to ultimately implement and then take an inventory of where you're at right now on all these elements, then you may find some changes that you can implement that are big "Bang for the Buck". That is, look for those changes that are the least costly and involve the least human upset and implement those. You'll start to get returns right away and, if they're successful, you may find some internal support for the more difficult changes you've got planned. In less than a day with minimal technical knowledge and tools that are almost certainly available within your organization right now, you could have, for example, a project information system that works on-line and can be used to inform project team members of updates on the project.

Having said all of that, it's true that a change in tools is often a great opportunity to sneak in a culture change. So next time we'll look at what kind of collaborative project management software is on the market and how you should go about choosing it.

For more information on this article or any aspect of project management software or systems contact the author, Chris Vandersluis or HMS Software at info@hmssoftware.ca or by phone at 514-695-8122.