30 January 2009

Nice Intro to Enterprise 2.0 and BPM

As you can probably see here I am always looking for good ways to explore and explain Enterprise 2.0 to people at different levels of the journey. The trick, I think, is to expand their tent a little at a time. Give them a taste of the benefits then introduce the next set of ideas.

Today I linked to Mark Masterson at Computer Sciences Corporation in their Germany office.

I came across him after his post about Enterprise 2.0 and organisational culture turned up in my weekly Google search results. I plan to continue my conversation with him next week on that subject, but it's nice to find somebody on the other side of the world with such similar interests and viewpoints.

Mark has posted some presentations on his Linked-In profile that take aim at those looking for process automation and pointing out the benefits of using (Gasp of horror!) humans instead of computers to do some tasks that - as it turns out - computers really aren't that good at doing.

So, if you are at the crux of developing business processes, or have crashed and burned a few business system projects, then have a look through. It's just 24 pages, explains itself pretty well and is definitely worth your time.

21 January 2009

The confluence of PM and KM

I have been studying informally for the CAPM exam recently and while doing so have been aware that while the PMBOK Guide discusses a "Project Management Information System", the technologies involved in this are less well described.

Last week I put a cal out on ActKM for those interested in joint developing a set of Project Management templates to be used in a wiki and I am now putting the call out here too.

There are a few reasons I think wikis would be a good tool to manage projects:
  1. In small businesses especially, the large PM tools are way too expensive. Using Creative Commons we will make these templates free for anyone to download. All you need is a wiki to install them on.
  2. Project Managers in general seem to be more of the box ticking type than the Barak Obama social types. As Sonal Shah points out in this nice blog post, Project Managers need to communicate more.
  3. Many of the documents are of a collaborative nature anyway. Stakeholders especially can benefit as a recursive process of creation for the requirements document tends to jog the mind and uncover needs in respond to other stakeholders points. erfect when stakeholders are on different continents or cannot meet for other reasons.
  4. The social nature of wikis means your team can work collaborative way. It traditional, highly siloed projects, the team members can see what the other parts of the project are up to, and in more modern projects, the Project Manager can encourage collaboration, especially around interface points.
  5. Finally, the visible nature of the wiki means that not just Project Plans and Status Reports, are visible, but also the project process itself. People can see what comes next and make more holistic decisions.
Interested in helping out? We will be using Atlassian Confluence and it will take some time, but if you think you have something to add then fire me an email of comment on this post. I look forward to hearing from you.

19 January 2009

Implementing KM with Social Knowledge in mind

Today I responded to a Linked-In question by Pervez Z. Khan and thought I would share it here as I ended up collecting my thoughts in the answer.

Pervez is a Communication and IT Consultant in Saudi Arabia and his initial question was:

Any help in identifying tools for generating knowledge, capturing knowledge and sharing knowledge

I am participating in a project to prepare a road map to establish a KM Strategy and Phased Implementation. I need to oversee the Role of IT in establishing the KM center and tools required for generating, capturing, sharing knowledge. In addition, methods, models, strategies, strategies, bench marking of best practices and Knowledge Center Planning and Implementation Phase Guidelines for a telecom service provider company.
Any link or help will be appreciated.

There were quite a few good replies but many of them followed the assumption in the question that Knowledge is about measurable, documentable information flows. The discussion can be viewed here.

John Malony had responded about the problems with this outdated view of KM and Joseph Colannino had posted a great little case study of the successful automation of the information flows around their R&D process. My response is below.

I tend to agree with John Maloney. Joseph Colannino's answer about knowledge audits is brilliant, but is actually an information flow audit. Much of knowledge work is actually done socially, however this doesn't mean it cannot be assisted with IT tools.

Enterprise 2.0 solutions like wikis, blogs and tagging are a way that some of the social exchange of knowledge can not only be captured in process, but also expanded in scope, allowing remote employees to enjoy the same level of connection as local staff do.

Implementing these tools is not the same as putting in an ERP of DMS. It requires an evolutionary framework that is modified not just due to the changing business requirements, but also by whether it is used or not, ie: does it suit the corporate culture and if not, is it close enough that a change management program addressing both cultural and software function issues will make a difference.

Security is also slightly different in this area and a combination of clear guidelines and structured zones or domains for internal and public information should be provided for.

Finally, one of the key productive outputs of enterprise based social networking is that of serendipity. This tries to make use of Clay Sharky's "Long Tail", ie: those people who have little to do with a project or operation, but the one thing they can add might save the entire project. To make the best use of this requires high levels of involvement, which is most often stopped by 1) bad usability, and 2) lack of management support. As IT manager, the first one is right in your domain. The second should be championed by the local manager to get executive support early on, or before the implementation.