Getting Real about Project Management, Collaboration, and Communication
I’ve recently learned — and re-learned — some useful lessons while working with clients and teams on projects and large proposals. These include:
- People adopt technology at different rates.
- People collaborate and communicate in many different ways.
- Some people don’t know how to collaborate.
- Technology is a collaboration tool, not a collaboration solution.
- Management needs to lead adoption and use of communication andcollaboration technologies.
My use of information technology to support project management seems to have come naturally. As an early-on gadget lover I gravitated towards data sharing technologies, web based publishing, and eventually to social media and social networking.
I’ve also found it’s a mistake to assume others share these same values. Even if they express willingness to collaborate, some project staff may require help from management or other team members learning how to use technology to support collaboration, especially if they’ve come together from a variety of organizations or backgrounds.
A typical project situation is where staff are working from many different locations and time zones on a time based project of some kind. Examples are developing a report, creating a proposal, developing a plan, or building and rolling out a product or application of some kind. Figure 1 displays a simple overview of how communication, collaboration, and project management can interact in such situations.
Figure 1. Project Collaboration map
All activities takes place in a “project sponsor” environment — a company, a government agency, a temporary team of companies or individuals, or some other group of resources bright together to accomplish a common objective. The three overlapping areas shown in Figure 1 are Management (guiding, leading, directing), Collaboration (working together to accomplish a common objective), and Communication (sharing information). I put a “gold star” at the intersection of the three.
It’s not sufficient for project management to focus only on managing project activities, deliverables, schedules, and budgets. Management may need to orchestrate how people communicate and collaborate, hence the gold star. This means providing leadership not only in defining tasks, responsibilities, and expectations — typical “project manager” duties — but also leading in the sharing ofinformation and in working together with different individuals and groups to accomplish necessary objectives.
Management needs to provide and use the tools:
- If a collaborative document creation and editing system is being used to create a complex document, management needs to (a) use the tool itself, (b) make it known to those refusing to use the tools that they could be threatening the project’s schedule and budget by imposing extra costs, and c) make sure everyone knows how to use the tool! (If you’ve ever had to integrate changes made to separate Microsoft Word documents the day before a large proposal is due you’ll know what I mean!)
- If a common calendaring or resource tracking system is available to staff members, management needs to (a) use the tool, (b) require its use when groups or individuals don’t make the effort to schedule group activities using the tool, and c) make sure everyone knows how to use the tool! (For example, don’t just toss a Basecamp application into a large mixed group and expect everyone to know how to configure and use it!)
Look again at Figure 1. You’ll see a lot of space outside the “gold star” intersection. Not all communication or collaboration can — or should — take place with the knowledge or involvement of management, and not all communication involves collaboration and vice versa. People are going to use their existing tools and skills; you wouldn’t expect anything different from any group of professionals, would you?
I still maintain, based on my own experience, that if management does not pay attention to the intersection of all three, project failure can result. Some of this management involvement involves imposing structure and discipline and making responsibilities and expectations clear and understood by all. This is partly so that spontaneous “outside the gold star” collaboration and communication emerge within a shared context — even if the actual methods adopted by staff are unique or even incompatible with what others are doing.
For example, a senior member of the team may only know about how to use email and attachments to share files and may resist using a shared document using collaborative when working with a large group. Inevitably the problem of incompatible versions or out of sync revisions rears its ugly head, usually at the worst possible time.
Even more subtle issues come into play when sharing documents even from a central location. File naming conventions need to be enforced and that means that someone may have to play the role of the enforcer. Also, despite ubiquity of Microsoft Office applications there will arise incompatibilities due to multiple versions of Word or lack of universal access to tools such as Visio. Some one usually has to step in to convert, or standardize — or impose order. And when that happens in a temporary or volunteer situations, feathers can get ruffled if things aren’t approached diplomatically.
It’s always useful to remember that, just because you define a process and provide an underlying set of tools to support that process, not everyone will understand or be ready — or willing — to apply that process. What do you do if you’re managing a proposal and a key volunteer member doesn’t follow the process — “fire” him or her? Or suck it up and figure out a work-around?
Remember, it’s called “collaboration” for a reason. It’s about working together towards a common goal.
Keeping that in mind really helps when you need to balance the seemingly obvious advantages of standard systems and procedures with the reality that team members’ communication and collaboration behavior are learned over a long period of time and may be very difficult to change overnight.
Copyright (c) 2010 by Dennis D. McDonald.
