Monday, February 26, 2007

Wikis and Blogs Transforming Project Management

This link goes to an interesting article about how Wikis and Blogs can change the workflow of a company. I thinks there is application to managing projects.

http://searchcio.techtarget.com/originalContent/0,289142,sid19_gci1184607,00.html

As a project manager, I see real value in using both in project work. I like the idea of using a Blog for communicating the project status to the team and the stakeholders. The monologue with comments becomes a place where stakeholders can pull information about the project when ever they need it. Traditionally the PM pushes out information to the team. I also like the idea of having the whole project history in one place. The helps to centralize the "story" of the project and collect lessons learned for the application in the next project.

Wiki’s are a great collaborative tool. When you have a team that is separated by time and or geography, I can see how working on a project schedule in a wiki would be valuable. Each member can input the expertise into the schedule listing tasks and durations. In the end there is a complete schedule that has the whole team buy-in. Other PM areas can benefit: Risk assessments, Quality feedback, an RFP process, even laying the ground rules for the project could be hammered out in a wiki. Even a project team that is local can benefit by working together… Project the Wiki on a screen in a conference room and take meeting minutes, document assumptions and capture “group think.” Then when the meeting is over, the team can continue making additions as ideas come to mind, everyone can access the information during their project work, and the team collaboration that was started in the meeting can continue.

The interesting thing here is transparency. If used correctly there are no hidden thoughts, no undocumented assumptions and no project surprises. These two tools allow stakeholders to look inside the project as it is happening. The stakeholders can interact with the project by commenting, asking questions, encouraging the team, etc. While the stakeholder is "watching" the inter-working of the project, they are validating the scope... "Is this what I really wanted as my deliverable?" If not, corrections can be made as early as possible in the planning or execution phase. If the deliverable is right, the stakeholder is able to watch its development and have a deeper understanding of how the use and deploy the final deliverable. There is an early "bonding" of the stakeholder to the project deliverable that will reduce the chances of the deliverable being rejected at birth.

Unlike the traditional status report that is e-mailed out every Friday and not read, the Wiki and Blog put the ownership of getting the project information on the stakeholder. Any time an update is needed (even if it is not Friday) a stakeholder can get an update. This is important... these tools may keep the stakeholder from calling or e-mailing the PM, using up both of their valuable time. And in the e-mail scenario, the stakeholder is waiting for a response from the PM, when they could have checked the Wiki or the Blog for an up-to-the-minute project status.

Yes the PM is responsible for keeping the tool(s) update. I would submit, however, that the PM can push some of the administration work of updating to the project team. The team members can input up-to-the-minute information on the status their tasks on the WBS. They can report successes and road blocks. In most cases the PM is calling, meeting with or e-mailing the team members. Then the PM is reforming the information from the team into a status report for the stakeholders. This takes a lot of time on the part of the PM and the team.

The same project status information, kept more current, in a conversational medium, accessible anytime, created with team buy in, that saves time and improves communication efficiency is worth trying.

Good luck with your try and let me know how it work for you.

Monday, February 12, 2007

Knowledge is the Fuel, Intelligence is the Engine

This morning on my commute I was listening to the Motley Fool Podcast interview of A.J. Jacobs. Mr. Jacobs went on a quest to become the world’s smartest man by reading the whole encyclopedia. He has written a book called “Know-it-all.”

http://www.podcastdirectory.com/podcasts/3179

In this interview Mr. Jacobs comments that “Knowledge is the Fuel, Intelligence is the Engine.” How true this is…

We are living in an environment where knowledge in abundant. Knowledge is created at a pace today we have never seen in all of human history. More than just the creation of knowledge, access to the knowledge is readily available and cheap. The Internet is the prime example of knowledge accessibility. In schools, libraries and our homes we find access to knowledge that exist as well as a view into the “crucible” where knowledge is created. Further, we can jump into the “crucible” at any point to join in the forging of new knowledge. We are at a unique point in human history.

Intelligence is another issue. (http://en.wikipedia.org/wiki/Intelligence) As I look at the world around me I find that intelligence is scarce. I do understand that not every one has the same I.Q. or abilities. We are all different in many ways and that is generally good. However, when people are faced with the simplest of knowledge, they do not know what to do with it. There is a blankness or paralysis when faced with knowledge. There is a lack of taking the next step (that only humans can do) and discovering insight and developing an opinion and then making actionable decisions. It is in the place where these actionable decisions are created that work is done, money is made and lives become simpler.

We humans seem to be developing tools that can handle and process more and more knowledge, but we as humans are not evolving our intelligence fast enough to keep up with the processing. We need more capacity to make useful decisions with the available data. So we build a faster and bigger computer (with our knowledge) that can turn data into information and crunch information into knowledge. But what are we doing with this knowledge? Are we now creating knowledge for the sake of creation? Have we created such a stockpile of “Fuel” that our “Engines” will never burn it all?

I’m glad Mr. Jacobs you are the smartest man in the world, truly I am glad. Why? Because now I know that I am not the smartest man in the world and that takes a lot of pressure off.

Now, what are you going to do with all that knowledge?

Wednesday, January 31, 2007

The Three Actuals

In Dr. Jih’s Blog on Knowledge management (http://kmspring07.blogspot.com/) there is a post about experience Pro and Con…

In my work as an I.T. manager and Project Manager I have come to learn that there are “three actuals” that need to be studied when providing solution or doing systems work. This feeds into how experience is important in Knowledge Management:

Actual #1: Go to the actual place. This is important when developing software systems, mechanical systems or work flow processes. Too many times in my early career have I thought I understood a user request. I created a solution from my perception and found out the square peg will not fir into the round whole. Experiencing the actual place will give you insight not other wise gained from an interview or written request. Some of what is gained at the actual place is explicit knowledge. Other knowledge, and at time more important, is the tacit knowledge.. The feel of the place, the observation of the way the people interact with other people or interact with systems and machines.

Actual #2: See the actual people perform. Understand from the end user the gap you are helping them to fill. Having the understanding that the user thinks a report will fill a process gap, an experienced process engineer may suggest a change in work flow that leads the people to a more efficient screen. If the engineer has not seen the actual people in their actual place then a sub-optimal solution may have been delivered. From a project management perspective, being with the people helps with solution buy-in. The people will feel some ownership in the solution and in the end accept the solution at project closure.

Actual #3: View the actual process. It is possible to visit the actual place and communicate with the actual people and still not understand the actual process. Again, if the process engineer is seeing a process different that what the solution will be applied to, then we may find out at implementation time the square peg does not fit into the round whole.

So, experience is important to knowledge workers. Especially the knowledge workers that are bring some kind of solution to a problem.

Knowledge Management Day-to-Day

The Knowledge Management class we are in has brought up a lot of new thoughts and is changing the way I am thinking about being a knowledge worker. The whole study of KM, which is new to me, is helping me to take a look at the knowledge itself, not just the content of the knowledge. I am starting to see in my day-to-day activities the progression from data, to information, to insight, to knowledge and wisdom.

It is interesting to realize that decisions I have made in the past may have been premature. While a correct solution may have been generated at the information stage, a better solution was just around the corner had I evolved the information to a higher level. Sometimes decisions have to be made with the available data/information gathered because of surrounding circumstances or time constraints. I am realizing that experience (and sometimes dumb luck) can be used to fill in the knowledge gaps when necessary.

Thursday, January 25, 2007

First Blog

This is my first blog entry for 6720 Knowledge Management Class.