Mapping our way to knowledge management.

Part of successful knowledge management in organizations will revolve around how good a job we do at drawing "maps" that help explain and represent this new territory. Dane Carlson offers pointers to some resources we can adapt to that task.

You Are Here: Maps 101. How to create a good map. I'll remember this for the next Talk Like a Pirate Day. via The Map Room: A weblog about maps, a good read itself.... [Dane Carlson's Weblog]

In the wonderful serendipity that using a news aggregator offers, Frank Patrick's Focused Performance weblog (a great resource on project management brings the following tidbit:

A Clarification on Maps and Plans. A Clarification on Maps and Plans -- I recently quoted Alford Korzybski, using his often cited statement,

"A map is not the territory."

Upon researching it, I didn't go far enough. The complete statement from is actually...

"A map is not the territory it represents, but if correct, it has a similar structure to the territory, which accounts for its usefulness."

Puts a whole 'nother spin on it, doesn't it?

Project plans and schedules can be made to model a "similar structure" to the project itself, sufficiently reflecting reasonable expectations of the future as well as uncertainty to be useful. (I think someone -- who was it? -- once said that "all models are wrong, but some models are useful." If that's so, then I'm comfortable with the idea that some models are more useful than others.) [Frank Patrick's Focused Performance Blog]

If those of us talking about knowledge management are exploring new territory, one of our responsibilities is to draw the maps that will encourage those who stayed behind to follow us and show them paths that are safe and interesting to travel.

[McGee's Musings]

6:17:04 PM    

Can you apply Theory Of Constraints to Human Capital?.

Frank Patrick (one of the deepest thinkers on project management in our time) catches the new chapter on Critical Chain Scheduling in Ed Yourdan's new second edition of Death March. The book is mandatory reading for every project worker.

I like one of Yourdan's anecdotes:

My colleague Tom DeMarco likes to tell the story of consulting clients he visits, who ask him, "If we could do just one thing to improve our project-management situation, what would it be?" Tom's answer is often simple: "Stop assigning people to work on five or six unrelated projects simultaneously; give everyone one project to work on, and leave them alone until they finish that one project."  Invariably, says Tom, the response is, "Well, yeah, that sounds very rational.  But you don't understand, that just wouldn't work in our organization -- because in our organization we have constraints A, B, and C, and we have to deal with political problems X, Y, and Z, so give us another one thing that could make all of our project management problems go away."  Any suggestion that attacks the dysfunctional behaviors in the organization is almost certain to be rejected with the phrase, "Well, maybe that would work in a perfect world -- but in the 'real world' where we operate, it could never happen because of X, Y, and Z"  And the organization eventually finds a "pill" -- a new development tool, a new systems analysis methodology, a new buzzword -- that may bring short-term relief, but rarely attacks the underlying problems.

Changes, deep ones, important and worthwhile, shake us.

The chapter is about more than change. It is about applying Goldratt's Theory Of Constraints (TOC) to project scheduling. It requires a different set of values, behaviors, incentives, measures, and project controls. So this calls for extensive change.

Human Capital Constraints

How can we apply the Theory Of Constraints to workforce planning and recruiting?

Where are the bottlenecks to be overcome?

Can the system design be reconsidered in light of the TOC?

What assumptions and dogma are worth challenging?

What new values, behaviors, incentives, measures, and controls will lead to more of what we want?

How can we get more of the right people on our radar? Spend more time spent in meaningful conversation and less on paperwork? Shorten our cycle times while increasing our quality?

Along the way, can we take some of the strain out of the process?

Now on my reading list:

• Project Management in the Fast Lane: Applying the Theory of Constraints
• Critical Chain Project Management.
• It's Not Luck.

P.S. When I was a kid I wanted to grow up to be a systems engineer. In high school I wanted to be an operations research analyst, reading Naval Operations Analysis. By nineteen I was working for the Naval Supply Systems Command as a civilian operations research analyst. My favorite book in the whole world was Quick and Dirty OR. Just to explain the utter and complete geekiness of this post.

[a klog apart]

6:13:29 PM