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.
