It’s the hot button lately in project management circles. How can teams collaborate? It’s not idle chatter. It’s been apparent for a long time that a project manager’s role is not just calculating a schedule from his hidden laboratory deep in the bowels of the organization. Now a project manager is expected to spend the vast majority of his or her time working with others. They may be negotiating with the clients or recruiting new team members or empowering and encouraging the team to be more effective or referreeing resource conflicts with resource managers. And that’s just one-on-one or with small groups. The project manager is also expected to speak publicly to the board or the media or the users or the team.

With collaboration being such a hot button it’s not surprising that project management software publishers and consultants are happily explaining how wonderful it will be for clients to improve their collaboration tools. I get such requests on a regular basis.

So let’s pause a moment and just review what collaboration means and what implementing better collaboration entails. Dictionary.com has a couple of definitions of collaboration but the most useful to this discussion is: “To work together, especially in a joint intellectual effort.” Not too useful for practical purposes but the idea is having people work together. Well, a project almost always involves people working together so we know we’re off to a good start. What might team collaborators collaborate on?

A few categories of how teams might work together might include document management, meeting management, communications follow up or working with virtual teams. Let’s tackle a few of these:

Document Management

One of the most popular things pointed to when talking about collaboration benefits is document management. In many project environments, moving documents around numerous participants in the project team can be a critical success factor. In high tech, these might be design criteria. In engineering, they might be archtectural plans or engineering drawings. In bio-research they might be regulatory documents. It seems attractive to link these documents to task reports when doing project schedule reports but the big benefits of this kind of collaboration process is managing the workflow of the document. Should this be part of your project management process along with schedule management? There are a couple of factors to consider. First of all, does your organization already have a document management system. Many large organizations do. If so, then going with the flow on a system that’s already deployed makes a lot of sense. Secondly, does your entire project team have access to it? This may not be so obvious. Many project teams extend beyond a single organization. If that’s the case, then setting up a parallel document management system for documents associated to the project might be more sensible.

Meeting Management

Meetings, Meetings, Meetings. They’re so common that many timesheet systems automatically include a meeting entry. (We get asked for one all the time with our own TimeControl timesheet deployments.) Having meetings is often collaboration by definition but how you conduct those meetings can make a big difference to the effectiveness of a project. Meeting management systems include numerous features such as agenda management, minute taking, meeting collateral management (such as reports that are submitted to be viewed by the partiicpants), attendance recording and even virtual attendance for those who are out of town. With so many organizations having to curtail travel and even inter-office movement in order to save costs and with so many project teams reaching outside the organization, an effective meeting management process and system can make a world of difference. Sometimes such meetings can have an immediate impact on the project inlucing changing priorities, changing resource allocation, updating risks and progress information. Just being able to record promises made in a regular project review meeting and being able to recall that information instantly at the next meeting can revolutionize project progressing. But, does this mean that that the meeting management system should be integrated into the project scheduling system? Possibly. The first place to look is to see how the meeting management process is integrated into the project management process. Then look and see if there is an existing meeting management system and if that system is available to all your participants. It might be more important to have meeting management linked to document management than to scheduling.

Virtual Teams

More and more we’re seeing project teams being defined outside of the walls and even the corporate organization. Teams might include the client and sub contractors and even regulatory authorities from outside the organization and executive sponsors and resources from within the organization. The team may extend not just beyond the walls of the organization, it might also extend into numerous time zones and even numerous countries. Just holding a telephone conversation can be a significant challenge if part of the team is just getting to work in the morning as another part is just leaving at the end of their day half-way around the world. Empowering the virtual team to work as a team can be a significant challenge that has to be addressed early in the project lifecycle. Being able to distribute documents, record virtual meetings for review by others offline, updating progress in multiple time zones and even just being able to deposit project deliverables and artifacts somewhere in a file management system that is managed and traceable can make the difference between a project that works twice as effectively or half. I have seen such virtual teams hum along at a breakneck pace, one group half way around the world is delivering aspects of the project that is being reviewed by a team on the other side of the planet in time to be updated by the first group as they return in the morning. It can move so fast that it feels like around the clock development and that too can pose a challenge. When the pace of work is twice as fast as some team members are used to, the project can go off the rails in an awful hurry. Systems need to be twice as vigilant if the work is moving twice as fast so deploying systems to allow that tracking to be done more effectively is essential.

Incident and List management

There are so many bits of data that get generated during a project that having a single place to track them can allow many people to connect quickly and effectively. Lists and artifacts can be almost anything. They might include commissioning lists, deficiencies, bugs, corrective measures or even just lists of team members. Having such information readily available to all team members can be a blessing. I’ve seen a number of projects where integrating such list management into the project system and having that system be outward facing; meaning available through the Internet improves the speed of managing those lists and identifying problems that must be addressed by other team members. Simple online list management can level the playing field quickly by allowing required intervention to be recorded that reaches any member of the team at any level. A process needs to be in place to prevent every team member from assigning incidents indiscriminately to executives but the ability to do so can make a project tremendously more effective. These lists are rarely at the level of tasks that are managed in the schedule yet they often are able to affect tasks in the schedule.

Communication with… everyone

Effective communication is everything to a project manager but when setting up your project environment its worthwhile to try to determine what kind of communication is appropriate for what kind of information. Will you be checking your FAX every hour? Is that how you’d like to transmit documents? Do you want everyone copying everyone on every email? Will you progress data in a physical meeting or can members dial in virtually? Will you be updating information via SMS on a cell phone or on an application on a smartphone? How about instant messaging? Just because you can instant message someone on their phone will you use this as a primary source of communication? What information should require instant messaging and if you’re going to use this does everyone on the team have access to the same instant messaging system and network? Figuring out your communications strategy before you start your project makes a huge difference.

Collaboration is a way of life in today’s project management world. Most project managers and project management offices don’t need a do-everything project management system but hoping that collaboration will happen by default is a fantasy. A smart project manager will organize how they want collaboration to happen before the project starts even when systems are already in place. Getting everyone onto the same page early often makes the difference between staying ahead of the project or living in reaction mode trying to catch up until the project is done.

I had the privilege of speaking to a group of project managers recently and the hot topic of the evening was the trend towards new “collaborative” project management tools. It’s true that “Collaboration” has become the latest buzzword in a sea of project management software vendors as they try to distinguish their products from amongst all the others.

Collaborative project management – it sounds like a great new process. After all, who could possibly argue against a collaborative process? The answer, of course, is no one. Project management by its very nature is a collaborative process. I’d sure like to see some pm software that is non-collaborative. If you’re not collaborating with someone, then you’re probably not doing much project management. Nonetheless, collaborative project management software is all the rage and from my many visits into the head offices of corporate culture I can understand why.

There is an almost universal problem I encounter when talking about project management; a problem to which almost all executives I come into contact with are intent of finding a solution for. The universal desire is for a cross-project, enterprise-wide resource capacity planning system. At one time this kind of functionality was not critical in a project management system. Project management software as usually applied only to a mega project where enterprise project management meant managing one project only. On mega projects, resources are often considered to have unlimited availability. Schedule is the critical factor. There are still pm environments like this but they are much rarer than they once were.

The most common project environment today involves many projects, all competing for a small number of highly skilled resources. Line managers, department managers or resource managers often control those resources. The projects themselves are managed by project managers who must assemble their project teams in an environment where they must compete against other project managers vying for the same people. This is the classic matrix environment and it is as common as can be in business today.

The structural tension between the needs of managing the employees and the needs of the projects to get completed is supposed to deliver a compromise which affords the best to everyone but it doesn’t always work out.

The problem is the human factor which is rarely considered when creating such an environment.

This week I had occasion to see this in action at one of our country’s larger telecommunications companies. (No, I won’t embarrass them by saying who it is.) I had been called in because management at this firm had determined that it had no visibility over the capacity of the organization to take on new projects and to model the impact of new initiatives as they occurred. It’s not a new request; I get it several times a week so I was well prepared to discuss the problem. I met with a selection committee who had been given a mandate to find a software solution to the problem. Would I update them, they asked on the ability of different collaborative project management software systems to perform multi-project resource analysis, capacity planning and what-if modeling ? Of course I would but my first question was to how they were operating now. Oh no, I was told, the existing system was completely insufficient for their needs. Well that wasn’t my question. It took some teasing (it always does) but finally they confessed that although multiple project management systems were in place, no two project managers worked together.

For those of you thinking I must be speaking about you organization, take heart. The good news is you’re not alone. The bad news? You have plenty of company.

This scenario is amazingly common. It’s true that my sample of data is badly skewed since the people who call me mostly have a problem they are trying to solve. Those who have great solutions don’t seem to look for my advice. Still, what amazes me is how a group of what seem like highly intelligent people can have the notion that the implementation of software will make project managers collaborate.

For this organization who seems intent on breaking out of the mold that they’re in, there is certainly hope but my comments to them involved very little talk about how features worked and a lot of conversation about how they will need to change the culture if they are to have any hope of success.

“Can’t we just have a multi-project resource leveling?” they asked. “Sure,” I said. “Please point to the person who will be setting the project priorities so that projects can be analyzed together without making a low-priority maintenance project get resources ahead of a company-critical development project.”

Hands were slow to rise. I can understand why. This will not be a job to be envied the first day that someone’s project has resources removed from it so that a higher priority project can move forward. Would someone be ready to sacrifice the productivity of their own project for the greater good of the organization? Would they give access to the resource records under their control with the risk that they be co-opted by someone else?

There was, I think, some misguided hope that the software would tackle that decision for them.

The great Diaspora of computing that started with the PC is coming back to haunt us. We’ve all become a little spoiled at managing our own data in our own world. The advent of centralized networked data is pushing some of back together in functions like project management. With the Internet making the technology of sharing data easier and web-based architecture pushing data back into a centrally managed source (onto a client-server database instead of in Excel on my hard disk), some of us are being asked to share; something we haven’t really had to do for a long time. Our notion of sharing has been coloured by an entire generation of PC users who say “well you share everything you’ve got with me and I’ll think about whether or not to share anything with you.” Centralized project management doesn’t work that way. It’s true that technology now provides us the opportunity to automate a collaborative project management practice but is our do-it-yourself generation ready to truly share? It was something I threw out to this group of project managers at the telecommunications company.

There is no doubt that everyone in the room desired a solution but I challenged them to deal with the corporate culture that caused the problem. Would they be able to collaborate given the chance? The jury is out.

It’s this year’s hot topic – “Collaborative Project Management Systems” – but what exactly does it mean and how should we deal with the wave of collaborative pm software tools that are arriving on the market?

I mean it’s like saying you’re American but you just can stand for Mom or Apple Pie.  Project Management is a collaborative process so it surely goes without saying that every project manager is in favor of a collaborative project management tool. 

The problem is, that project management software vendors are in the market too and now that someone has coined the phrase, it seems that 100% of project management systems are now “collaborative” project management systems.  Just how do you go about telling one apart from another and determining what collaborative functionality is important to you?

The first thing to deal with is to take a step back from your Internet-wide search of pm collaborative tools and think for a moment about where you and your project team need to be collaborating better.  Collaboration can take a variety of forms. 

Perhaps your projects are weak in the area of informing project team members, clients or sponsors about project information such as project progress, changes in strategy or targets etc.  In this case, bulletin board type functionality or group email functionality might be important.

Perhaps you feel that a two-way feedback from team members to each other and/or to the project manager or client needs improvement.  In this case an ability to chat on-line or to see who is currently available in an instant messaging type functionality might be of interest.

Perhaps you are moving a high volume of documents back and forth throughout the group and the management of key documents is what is slowing you down.  Ok, so it’s document management functionality that you could use.

Perhaps the statusing of your project is arduous and some kind of update tool from the end users to the project system would make you more effective.  Ok, then an on-line statusing and/or timesheet system would be what to look for.

Some clients have come to me and said, “But I need all of that!” why don’t I just buy an integrated-enterprise-wide-collaborative project management system?” 

Of course in some cases we will find weaknesses in how a project organization collaborates at all and in this case all of these types of collaboration might be critical but it’s worthwhile to note that regardless of the functionality available from these collaborative tools, there is always a culture-change component to changing the way you manage your business. 

For each of the scenarios above you can easily imagine how making such functionality available could inhibit the project process. 

A wave of on-online chatting for example, with everyone talking to everyone about everything they think hour by hour with the project client joining in to experience perhaps for the first time the angst that can overwhelm a project team in mid-stream.

Or perhaps an ongoing stream of instant messaging requests that keeps a team member from having an uninterrupted thought throughout his or her day.

Changing the way we do business is something that has to take into account the shear momentum of how things are being done now.  Change causes upset.  It just does.  Even if that change is for the better.  There will be people more or less interested in change but the comfort of knowing how things are done today makes many people reluctant to abandon that method of doing business in favor of something else.

The best way to go about taking advantage of some of the new collaborative project management functionality is to start with what needs the most help.  I was recently at one of the larger pharmaceutical supply companies in North America and found to my great interest that they had done exactly that.  This firm had determined that document management was the most critical area that required improving.  With all the regulatory requirements in the pharmaceutical industry, regulatory documents must often travel across countries, time zones and endure for a remarkably long time in good condition.  Also, the security of these documents is critical to a successful regulatory ruling.  It was the project management group but what they ended up selecting after a review of a number of project-specific tools was a document management system that was not originally designed for project work at all. 

Of course that’s not for everyone and many of the project specific tools seem to be credible products but the point I’m making is that you’ve got to decide for yourself what element of your corporate culture you need to change before trying to automate it.  Once you do, you’ll need to make a plan (I know, I know, project managers hate to plan their own systems) to implement that change that includes training, evangelizing and the use of course, of the software itself.

Collaboration Project Systems seem to be available on every corner but are we ready to use them?  This article looks at the challenges and pitfalls of implementing a collaborative project system.

It seems to be the subject on everyone’s lips – when will your organization move to implement a collaborative project system.  Virtually everyone’s getting in on the act.  At the project management seminars, every vendor appears to have an “enterprise project management collaboration system”.  “Enable collaboration!” we cry when the clients come near.  It all sounds pretty great and there is no doubt that the executive suite is finding the message very attractive.  ‘Just purchase our enterprise-wide license,’ explains the vendor, ‘and your entire project group will begin collaborating.’

Ok, perhaps I’m being a little facetious but the truth is, that’s far too close to the truth!  So you’re wondering if your organization shouldn’t get on the bandwagon and see if they can implement a collaboration system?  We’ll cover a primer on the subject in this column.

First of all, what is a collaboration system?  The answer is, of course, different for every system vendor but at its root, such a system extends classic project management functionality by allowing a degree of interaction between the project team members and both the project manager and each other.  Most systems do this by enabling several types of functions.  Given the ubiquitous nature of the Internet, virtually all of these functions are enabled by the universal interface of the web browser and the universally available network of the Internet itself. The first function, and the most obvious, is an alert mechanism that informs team members that something about the project that affects them requires attention.  This might be a new assignment or a change in schedule or just a reminder to get their timesheet completed.  Next you’ll find some kind of updating ability – allowing all team members the ability to enter status data for the project.  This might be as simple as a timesheet or extend to every aspect of task progress.  Finally, there is usually some kind of communications mechanism such as a Forum, or live chat typical of most web portal technology.

Where can you find this Holy Grail?  Everywhere I’m afraid.  This kind of functionality is now becoming quite common.  You’ll find it in everything from SAP to Oracle Project to Primavera’s suite to Microsoft Project Server and a lot of places in between.  There is even a range of open source solutions that provide this functionality.  This type of code can be found at SourceForge.net.  (There is usually some assembly required.)

You would think with this kind of functionality readily available – in some cases for only the cost of implementation that this wouldn’t even warrant an article – there would be no question – of course everyone is already doing this! 

This is not the case.  If you haven’t successfully completed the deployment of your enterprise collaboration system and are feeling terribly inadequate so far, take heart.  You are not alone. 

The challenge in implementing and deploying such a solution is not often in the technical arena.  The challenge is in the very nature of collaboration.  Some executive types might imagine that team members don’t collaborate with each other because they are missing some critical function in the enterprise systems.  It’s much more likely that team members don’t collaborate because the culture in which they work provides enormous disincentives to collaborate. 

Many organizations (the larger, the more likely) have gradually bred inherent barriers for employees to share.  These may include any of the following:

Power struggle
In some organizations, information is power.  If I tell you everything I know, but you don’t do the same with me, perhaps you can use your increased access to information to forward your own career at the expense of my own.  For example, if my project is currently running slightly late, you might be able to share that information privately in some circles while explaining that your own projects are right on time.  I might never get the opportunity to explain a perfectly valid reason for which my projects are late before finding myself out of a job.

Beaten by my own data
In some organizations, sharing bad news is tantamount to shooting yourself in the foot.  Some project managers will be unwilling to share schedule or cost project difficulties in mid-project for fear management will be in their cubicle in the morning replacing the project manager or micro-managing the project from now on.  Given that some projects often go through both positive and negative periods, project managers might have the experience that waiting until the final results are in would be a better strategy – who knows, the project might end up better than we think, or perhaps there’ll be a change in scope tomorrow that will hide the project problems or perhaps my manager will get promoted and a new guy won’t have a clue how we’re supposed to be doing.

The mythical 40-hour day
In many organizations, particularly those in the high-tech field, there are often a very small number of ultra-key resources.  Without these people, the core of a project is undoable.  This might be someone who has intimate knowledge of the legacy systems’ architecture or someone who has a particular mix of skills and knowledge to be able to perform key design and construction of the kernel of systems.  Sometimes it is a particularly clever person who knows how to do a certain type of calculation (writers of resource leveling algorithms come to mind).  In a multi-project scenario (virtually every high-tech firm has one) every project manager schedules these resources at 100% of their time.  It’s very common when putting an enterprise project system together that one of the first results is finding out that a small handful of resources are scheduled at 200 hours per week.  The project managers who have been able to get access to these key resources often do so with the finesse of great interpersonal relationships, friendly persuasion and so on.  These are the most productive project managers and if we deploy a collaborative project system where they will have to share their true resource requirements with everyone, these resources will become harder to hold onto exclusively as they may have done in the past.  So – these project managers must resist such a system regardless of its benefits.

If you think of all these effects, they are the very things management wishes they could remove and the very thing that the culture of the organization will try to keep in place.

Aside from the cultural barriers, there are other challenges for a collaboration tool deployment.  The technical issues can be significant.  Yes, it’s true that end-users who see such systems enjoy a very comfortable level of interface as the ease-of-use of such systems is usually excellent.  But for all of that, the installation and architecture issues may be challenging.  You should be considering:

Client Hardware/Operating System/Browser compatibility
It may all look great in Internet Explorer but will you have some users (perhaps out of the country) who will be trying to collaborate using a Mac OS9 with Netscape?  You’ll have to check the systems you’re implementing for such compatibility issues.  You need to check the hardware, the operating system, the browser and sometimes even the Java Virtual machine versions to ensure compatibility. 

Security
This is particularly poignant if you are considering a system which must be “outward facing” meaning that users will access the system from outside your corporate firewall through the Internet.  If not well architected, not only might the security of your collaboration system be compromised, you might open a path to other corporate systems.  You might need to consider VPNs or other security measures.

Bandwidth, connectivity
What kind of network traffic will the system generate and is your network ready to handle it.

Hopefully you’re still reading and I haven’t scared you off.  If you plan to deploy a collaboration system, here are some tips to avoid the worst headaches:

First, make the deployment a project and treat it like every other project in the organization.  This includes having a sponsor, a charter, a budget, a schedule etc.

This type of deployment should be managed as a change-management project.  This is not an uncommon type of project – it’s just like any major change in process – but if you treat it this way, you will avoid a range of errors that are bound to occur if you treat this as a simple software installation.  Remember, unless you are a brand new startup (and even sometimes then) your organization already has a way of working that has its own momentum.  You will find it easier to gradually redirect the momentum into a new direction than you will to simply stand in the face of it hold your palm up and say ‘talk to the hand’. 

For those issues which are bound to be contentious, get buy in from many sources.  Go out of your way to encourage input.  Nothing will get someone’s back up faster than to deliver an edict that you have to deploy through threats and force.

Make sure you manage expectations. Leopards don’t change their spots overnight and not everyone wants to share all their data.  Management in particular needs to understand that the change in culture will occur over time and they will have to contribute their patience for the project to succeed.  If you are in system selection mode, put a heavy emphasis on flexibility over functionality.  It’s fair to say that the way you use the system in the end will be heavily influenced by the users themselves as it is deployed and you will be happy you can flex with their demand as it evolves.

Finally, get help.  The system vendor of the product you select will have numerous resources available and consultants, if used sensibly, can often get a message across that is difficult to hear from someone inside the organization.

Article: Collaborative Project Management – How to start collaborating
If you’ve already decided that collaboration will be a significant element of your project management environment, here is an article that talks about how get started with your collaboration efforts.

Article: Collaborative Project Management
How can collaboration impact our project management environment?  We’ll look at some basic collaboration building blocks in this article.

Article: Collaboration? Who’s collaborating?
When you consider the collaboration aspect of project management, it’s worthwhile to come up with a collaboration plan much as you would a communications plan for a project.  Who should collaborate, how should this collaboration be facilitated and/or moderated?  What should you collaborate about?  We’ll look at the essentials of project collaboration in this article.