Kyle Smith

A few months ago I read 97 Things Every Project Manager Should Know and one point that really stood out for me was Adrian Wible’s recommendation to use a wiki for maintaining project information.  There are a number of positive aspects of using a wiki, but Wible doesn’t even allude to the many downsides:  page sprawl, the difficulty in finding information, and keeping it all up to date, which I feel outweigh the positive benefits.

At VMware we’ve had wikis for engineering teams to post project information for a number of years now but it’s become more of a dumping ground than a useful reference.  In the last few years our use of the wiki has exploded, but engineers are busy so they tend to “fire and forget”: content gets posted but no one bothers to go back and update it.  And because wikis set the bar extremely low, people just throw in content without thinking about findability or how to properly take advantage of hypermedia.

The result is that it’s extremely difficult to find the page or content you’re looking for.  Our Google Search Appliance doesn’t even help because there aren’t enough quality links for the PageRank algorithm to produce useful results (that’s my guess anyway).  So instead of finding a page with details on how our virtual machine monitor works, you’re more likely to get a page full of daily status log entries.

Perhaps the best solution is to do what Wikipedia does: establish standards for content, linking, and organizing the information (it also helps to have a volunteer army of curators/librarians to maintain it).  Of course, this is easier said than done.  Companies like VMware make money by shipping products, not pruning wiki pages, so it’s difficult to sell the idea of having all employees act as part-time curators unless you can quantify the ROI. Sadly, I don’t have an answer for that (yet).  Some inexpensive alternatives that come to mind are to hire a librarian to prune and organize or to have the company’s Intranet team help establish the best practices — assuming they’re good with information architecture and not just throwing up Web pages).

While all of these options focus on primarily Web content, the overall problem of capturing organizational knowledge is much larger.  Hopefully more on this soon…

Tags: 97-things, information-architecture, wiki

While reading Chip and Dan Heath’s book Made to Stick several weeks ago the following point caught my attention:

Many armies fail because they put all their emphasis into creating a plan that becomes useless ten minutes into the battle.

A similar problem occurs when planning a software development project.  A significant amount of planning can occur and then when the developers start writing code, the plan goes out the window.

So what is the solution?  The Heaths explain the answer to the traditional case: a concept called Commander’s Intent that was developed by the Army in the 1980s.  I had not heard of CI before reading their book, but came across it again today in James Surowiecki’s The Wisdom of Crowds.  For those not familar, here is the explanation from Made to Stick:

CI is a crisp, plain-talk statement that appears at the top of every order, specifying the plan’s goal, the desired end-state of an operation.

The CI never specifies so much detail that it risks being rendered obsolete by unpredictable events.  “You can lose the ability to execute the original plan, but you never lose the responsibility of executing the intent.”

Perhaps in the software development case the notion of CI manifests itself as a release theme or goal?  If this is true, it’s not clear to me how much value it actually provides because there are no details.

With the CI at the top of any order a soldier essentially knows the minimum amount of work that needs to be done.  With a CI in a software project plan it doesn’t seem to define the scope of the release well enough.  Or does it?

Tags: agile, commanders intent, communication, made to stick