Progress On Open and Collaborative Project Management

By Dennis D. McDonald

Click or tap image to download a .pdf of this articleDesigning open projects

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 to  link 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. 


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, Ph.D. Dennis is a Washington DC area consultant specializing in collaborative project management and new technology adoption. His clients have included the US Department of Veterans Affairs, the US Environmental Protection Agency, the National Library of Medicine, the National Academy of Engineering, and the World Bank Group. Contact Dennis via email at or by phone at 703-402-7382.

PrintView Printer Friendly Version

EmailEmail Article to Friend

« What Does "Open Access" Mean, Really? | Main | Why I'm Avoiding Google+ Today »

Reader Comments (10)

Dennis, thanks for your feedback while I was writing the paper and additional insights now. It took me a lot longer to pull this together than I'd hoped (I'm clearly not going to write for a living!) and your attention and encouragement matters.

I agree that blogs represent a lot about what is good in open project approaches - they are low-overhead, widely available, easy to share. Managed well they can be instrumental in many of the "tips" including letting others play, playing nice, narrating our work, and using flexible communications channels.

I also agree that thinking hard about what we mean by "platform" is a huge opportunity. Most projects set out to resolve a specific problem but, by focusing too quickly on the near-term issue, miss opportunities to invest in infrastructure, to convene different groups and scale, and to solve more fundamental problems or create much more influential, innovative, long-lived, impactful, resources.

For those of us interested in Federal work, O'Reilly had framed a good question by asking what we mean by "government as a platform" - how can we move from government answering questions to government providing infrastructure to support citizens to answer their own questions? (Here's Tim's chapter:
September 17, 2012 | Unregistered CommenterDavid Witzel

Thanks for the comment and for the link. I've sent chapter 1 of O'Relly's document to my Kindle and look forward to reading it.

When it comes to projects the focus on "platform" is important. Traditionally we have wanted to have organizations running on common platforms for communicating -- common phone systems, common email systems, common financial and HR systems, etc. As the boundary between the organization and its public becomes more porous, due to the need (and ability) to interact with people online on the networks where they actually interact themselves, we are faced with a possible proliferation of platforms given how easy it is for people to move from group to group. If we follow the philosophy "go where the people are" we have to assume, don't we, that Government agencies will have to support multiple platforms and communities, as we see already with multiple Facebook and YouTUbe groups and multiple Twitter accounts. This would seem to fly in the face of a traditional desire for platform standardization, wouldn't it?

- Dennis
September 17, 2012 | Unregistered CommenterDennis D. McDonald
Yes, I expect that government will have to engage on many communications platforms. We're going to have to figure out ways that allow cross-platform activity and live with the fact that we're unlikely to have many more monolithic communication platforms.

But, maybe more important, we don't want to assume that all important platforms are for communications. Broadly speaking, platforms are a way to connect multiple groups, each having different needs, in a way that helps them meet their respective needs. Thus, MSFT Windows helps computer makers, device manufacturers, and software developers, serve computer users. Likewise, a shopping mall let's lots of stores have space, facilities, and parking to get access to lots of customers.

One of the fun challenges will be, what other kinds of platforms, connecting what groups, serving what sorts of social needs, should be created?
September 17, 2012 | Unregistered CommenterDavid Witzel
Dennis, you guys know I respect you but I've got to call you out for smoking too much dope on this open collaboration stuff. Collaboration is useful and essential but it's also not a binary setting with an on/off switch, it's analog, and dialing-in the right setting is really important. Too much = bad, too little = bad. It’s possible to have all the collaboration in the world (Dreamliner) and still have a terrible project experience. Openness and collaboration are not of themselves predictors of outcome. When conditions are favorable they can contribute a return but under less favorable conditions they can get in the way and can even be a negative influence on project success.

While it sounds great to "let everyone play" and all that stuff, the focus needs to be on innovation and skill development - not collaboration. Collaboration does not make an innovation strategy nor does it help people become ranked experts in their fields. Innovation exists in open highly collaborative environments and just as often in closed functional environments...and in between.

In places that have problems, collaboration isn't really the cause and neither is a lack of openness. A lot of the attention on collaboration addresses non-problems and I believe distracts us from the real challenges of the age. The problem is that most projects turn people into zombies, i.e. people perform their daily tasks but aren’t cognitively engaged in purposeful practice. It takes about 10,000 hours of purposeful practice to become a ranked master at any subject. Consider the guy who drives an hour to work every day, he racks up thousands of hours of driving practice – but that doesn’t qualify him to drive for NASCAR or as a stunt driver in Hollywood. It’s because he’s gaining experience but not practice. The same thing happens to people at work, they perform tasks but don’t press themselves to do things they are unable to do. While I don’t have any problem advocating effective collaboration techniques, we really need to put energy on how to fully engage knowledge workers in tasks that advance their abilities and fully engage their frontal lobes. From there we can attain elevated standards of performance in both productivity and innovation. Collaboration will occur more or less naturally in such environments and we can stop making a big deal out of something that is essentially human nature.
September 18, 2012 | Unregistered CommenterT.Scheer
Thad, I absolutely agree that why you collaborate and what form the collaboration takes are both important factors in getting work done. But assuming that people will collaborate on their own without any management direction or leadership is also shortsighted. When people are prevented from communicating and collaborating across organizational boundaries, as is the case with many organizations in both the government and private sector, opportunities for good things -- like innovation -- are lost. For some discussion of how the same collaboration tools can support a variety of different organizations, see the white paper I did for Jive Software, "Assessing Readiness for Enterprise Social Software" located here:
Thank you for your comment!
- Dennis
September 18, 2012 | Registered CommenterDennis D. McDonald
Interesting but I'll direct your attention back to Conway's Law that states (I'll paraphrase) that the communications pathways present in a technical architecture will mirror those of the organization that produced it. Conway's Law doesn't imply that one drives the other; it merely says they both end up aligned.

Thus, if one emphasizes the product being made - the communication pathways in the organization will naturally develop sans external coercion. With a culture that is accountable to innovation there is no need to put cycles on collaboration - it will simply happen. However, emphasizing collaboration will not necessarily induce a culture of innovation.

That's not to say we shouldn't encourage creative collisions and all that jazz. There's a fantastic bioresearch lab on in Leesburg, they bring in top researchers from all around the world but there's huge diversity in their specialties. Some are experts at microscopy while others are neuroscientists and whatnot. The building architects who designed the facility very cleverly designed the entire structure to encourage creative collisions between people of different disciplines. This is great for collaboration but it's just a supplemental benefit. Primarily this organization has emphasized recruiting the best and brightest, giving them a purpose, and creating a structure of research accountability. The creative collisions are an adder, not the strong center.
September 18, 2012 | Unregistered CommenterT.Scheer
Nice to make your v-acquaintance Thad! Of your two words "open collaboration" I'm actually more excited by "open" then "collaboration" - dope or no dope. That's the point of the paper - that open, porus projects have lots of good results including attracting good collaborators, fostering innovation, and having the possibility of reaching large scale.

Skill development is a case in point. Well-done open projects will allow people to participate at the "right" skill level and on the appropriate tasks, provide resources for (self-guided) skill improvement, and provide a selection of motivations to attract high skill people to participate. The fact that participants choose whether and how to participate also helps to avoid the zombie problem you mention.

I'd argue that traditional, top-down, closed, projects are more prone to and less responsive to the problems you pose than organic, porous, open projects.
September 18, 2012 | Unregistered CommenterDavid Witzel
Thad, one thing to consider is that innovation is not the only outcome from collaboration; see "Defining and Measuring Enterprise Collaboration" located here: .
September 18, 2012 | Registered CommenterDennis D. McDonald
I think the true nature of "collaborative" tools inside of organizations is something we've yet to fully realize. We've moved from blogs to enterprise social networks and are now seeing tools that take things a step further by putting users in change of reinventing process, which is where this all leads. I recently had the pleasure to meet and speak at length with Podio co-founder Kasper Hulthin and we talked a bit about this. Podio, now part of Citrix, is a tool that encourages the creation of "apps" which are really workflows, that can be exposed inside the organization, outside of the organization of in a hybrid fashion. The default user profile allows for anyone to create these "apps" and have a hand in changing how information is gathered, shared and processed. I suspect that many large and established organizations may eschew diving right into this level of empowerment and collaboration, but I do expect to see flatter structures emerge that are dependent upon participation and creation of value versus just descriptions and the fulfilling of role-based duties independent of constantly-shifting goals and expected outcomes.
October 4, 2012 | Unregistered CommenterChris Silva
Chris, thank you for the comment!
One possible approach to promoting adoption of the tools such as the one you describe is to focus initially on well defined workgroups where the need to interact, process-wise, with external groups can be controlled. I've found that overcoming internal-external boundaries is a frequent stumbling block in adopting tools that support knowledge sharing.
- Dennis
October 4, 2012 | Registered CommenterDennis D. McDonald

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.