I always enjoy reading project management articles that are written for specific industries, and then seeing if they also apply for managing projects outside of those industries.  This morning I came across one such posting on one of my favorite blogs, Heavy Mental.  Although the post describes the ten keys of project management for an enterprise 2.0 project as presented at the Paris forum, many of these rules could be used verbatim in KM projects or IT projects or even Library projects.

1) Manage risks from the early stages of the project
2) Seek Executive supports
3) Know your business needs and address them
4) Knowledge sharing in complex and fast paced changing environment for distributed workforce is a common motive
5) ROI may be complicated to evaluate but some benefits are unassailable
6) Usability is key for quick adoption
7) Cross functional participation is critical
8) IT support is critical but IT Governance is crippling
9) Don’t use the S word
10) Top-Grassroot-Down is the new Bottom-up

Rules 1-7 are pretty straight forward project management rules that can be used in almost any project you’re managing.  Rules 8-10 are pretty specific to the Enterprise 2.0 project topic, but with a little modification could be used in almost any PM topic.  I do love how IT is specifically called out for being a necessary evil in this project, but let’s face it; almost everything we do needs some type of IT support these days, but doesn’t need to be run by IT.  This topic was covered in a post on the Cloud Ave blog called “The Art of the Enterprise: Marketing Shrugged.”  In that post, there is a hypothetical (at least I assume that it was a hypothetical) where one department did its best to boycott IT altogether because they did not want the project to go into the black hole of IT Governance.  

Rule 9 specifically uses the “Don’t use the S (social media) word” for this Enterprise 2.0 topic, but there are many taboo words when it comes to project management in specific areas.  I heard some KM managers say that they specifically no longer say “This is a Knowledge Management Project” to their attorneys or administrators.  We all know there are certain words or phrases that raise the hackles on the back of some necks around our firms, so the best thing to do is to come up with another way of presenting the project without using the taboo words that cause such negative reactions.

Rule 10 is worded a little strangely, but basically says that Top-Down and Grassroots-Up are both essential to managing successful projects.  Buy-in is needed on all levels and no longer can you force a project upon the end-users (no matter how great the project), nor can you make an unusable project work (no matter how enthusiastic the end-users are about the idea.)  

Regardless of your project, these are ten good rules that can be adopted to fit your needs.

  • Greg, would you please expand on this idea? IT support is critical but IT Governance is crippling


  • Scott,

    What this means is basically "who has control of the project?" This probably never happens at your firm, but there have been times when a "marketing project" or "KM project" that needs support from the IT group suddenly becomes an "IT project" and goes into the long queue of projects that are already on the IT group's plate.
    A solid example can be found in the "Marketing Shrugged" story that I linked to in the post. The IT group can be an essential partner in supporting a project, but if IT ends up completely managing the project, it can cripple the original intention of the project.

  • I follow you. I believe it happens at just about every firm. From an IT standpoint, we would rather be a contributing member, not running the project. We feel it is the best use of our skills. Unfortunately with some projects nobody wants to lead and IT ends up with ownership because it involves technology. Project Management really helps with this problem, by clearly defining roles and project scope.

  • Greg,

    You might be interested in this article: Manage Your Project Like Attorneys Manage Matters. This one compares Project Management to handling a case.