By Dennis D. McDonald

Introduction

My friend Dave Witzel posted an article titled 12 Leadership Lessons of Internet Pioneers in which he summarizes the findings of a recent report he did for IBM’s Center for the Business of Government, Designing Open Projects: Lessons from Internet Pioneers. Here are Dave’s main bullet points:

1. Let Everyone Play
2. Play Nice
3. Talk About What You Are Doing While You Do It
4. Use Multiple Channels of Communication
5. Give It Away
6. Reach for the Edges
7. Make It Work, Then Make It Better
8. Make It Work, Then Standardize
9. Take Advantage of All Types of Organizations
10. Design for Participation
11. Increase Network Impact
12. Build Platforms

This list, Dave’s report, and its emphasis on open communication and collaboration got me to thinking about how my own approach to collaborative project management has evolved, starting with my own investigation of blogs as basic project management tools.

Blogs as project management tools

I’ve always thought that blogs can be useful project management tools. They typically combine easy web or intranet publishing, document sharing, and discussion features, plus the ability to integrate with a variety of external tools and data sources. It’s now pretty common for project management tools to incorporate basic group management, collaboration, sharing, and document management features.

I’ve also been in situations where I have adapted standard tools such as Google Docs and SharePoint to support project management. But I’ve found it’s not always easy to use these tools in the real world, especially in larger organizations with entrenched processes and procedures. Also, too much emphasis on tools per se can be a bad thing, which I think is one of the underlying themes in Daves report.

Wish list

Back in 2008 Lee White and I had an online conversation about social media, collaboration, and project management. From that year, here’s my wish list for project management tools:

• A centralized project intranet with integrated reporting tools, content management, and collaborative content development (e.g., blogging and/or easy to use wikis incorporating version control and version access).
• Voice, text, and video communication among all project staff, complete with “presence” indicators to tell when individuals are online and available to converse.
• An easy way to create and dissolve both permanent and temporary workgroups.
• Integrated time reporting so I can see what project and non-project work my project staff are committed to, now and through the forseeable future.
• Personalized web pages that incorporate individualized views of tasks and responsibilities (including dependencies, what’s late, and what’s next).
• The ability to mix and match control models so that both discrete, defined tasks as well as more flexible group oriented agile work techniques can be incorporated into the same overall management and reporting structure.
• The ability tolink an object to a discussion thread that can be tracked over time, bookmarked. tagged, and made universally searchable.
• Universal search against all objects, universally available tagging, and universally available RSS feeds (and an easy way to subscribe and unsubscribe).
• Automated support for tagging.
• Automated support for updating skills and expertise profiles based on project communications and work accomplished.
• The ability to view all project activities and associated objects at a 30,000 foot level and at a micro-level, and the ability to customize, store, retrieve, and display updates to these profiles over time.

Today’s reality

Looking at this list from the vantage point of 2012, I think it’s pretty heavily project metadata oriented. But it does point to the last bullet in Dave Witzel’s list, the one that talks about “platforms.” What I think of these days when I think about a client’s project management requirements are “What kind of communication and collaboration platforms does this client already have?” and “How hard or easy will it be to implement some of the things in this wish list?”

A dedicated piece of project management software and the ability to rapidly set up a project-focused intranet site (say, via SharePoint, Google Drive, or Microsoft SkyDrive) are only part of the answer. Also needed is the ability to communicate and share information openly with a group of people. This, in my experience, always includes group members with varying levels of interest and dedication to the project.

Some group members may also be outside the organization, so their access to a common communication and collaboration platform may be problematic. Also, the larger and more complex the project, the more likely that boundaries introduced by geography and organizational siloing will impact the ability to set up and operate a common platform where information about what people know and what they need to do can be easily and rapidly shared.  

Email, again

The common fallback — universal accessibility of email — is one of the reasons why moving to more collaborative document sharing and task management tools is delayed. Given that email is such a known quantity, arguing over its inefficiency for shared document access may not resonate with those who aren’t dedicated 100% to your project. Email is not going away.

Bright spots

Two bright spots have emerged since 2008 when I made the above list:

1. Social network platforms
2. Smartphones & tablets

Social network platforms such as Facebook and Twitter have accustomed people to quick and easy sharing of images and information among groups that may have little to do with formal organizational or departmental boundaries. IT departments are faced with employees wondering why they can’t communicate as easily inside the organization as outside the organization. This is one of the reasons, I think, that Microsoft bought Yammer. 

Smartphones and tablets put sophisticated communication and content consumption features into everybody’s hands in form factors that are portable and — arguably — more enjoyable to use than traditional desktop and laptop computers. Again,  IT departments are faced with having to manage a “bring your own device” (BYOD) movement where some employees would like to use their own smartphones and tablet computers as working tools. 

Conclusions

We should probably rethink what we mean by “platform” when it comes to the communication and collaboration that need to take place in a large or complex project.

It’s not just about the tools, documents, or formalisms traditionally associated with project management. People also need the wherewithal and leadership to share information, regardless of toolset. Witzel’s list points us in the right direction on this. 

It’s not likely that a “one size fits all” tool will emerge to satisfy everyone’s requirements. While I know of smaller organization that rely on the sharing and realtime collaboration features of Google Drive to run projects, older and larger organizations may not have the liberty or capability to implement such solutions across the board.

Managing projects through reliance on multiple platforms for project management, communication, and collaboration may simply be inevitable.

Unless, of course, employees take us in a different direction if they increasingly integrate social networks and mobile devices as a normal part of work. If we can figure out how to efficiently incorporate the features of such tools into the complex project management mix and do so without “killing the communication goose that lays the golden egg,” we may be able to really change and improve how projects are managed in our organizations.

Copyright (c) 2012 by Dennis D. McDonald