Published: 26 October 2016
Ron Ross recently had an excellent article on Modern Analyst titled "The Story of Al's Spreadsheet and Absent Brains" in which he makes several very valuable points. Those include:
Around the globe there is extensive core operational business knowledge running businesses day-to-day that is highly inaccessible. Just putting your fingers on it, much less revising it, consumes vast amounts of vital resources. We live in a service provider’s dreamscape. It makes you wonder how brittle (read not agile) many companies’ operations really are today.
To ensure the continuity of operational business knowledge, no organization should ever depend on absent brains – or even on brains that could (and eventually always will) become absent in the future. To say it differently, your operational business knowledge should be encoded explicitly in a form that workers you have never even met yet can understand.
Operational business knowledge can be either tacit or explicit (read ‘accessible’). The classic test for when knowledge is tacit is ‘lose the person, lose the knowledge’.
The closing paragraph of his article is, So make sure when you lose your Al, he doesn’t walk out the door with the day-to-day knowledge you need to run your business. Encode it as business rules!
Of course, business rules are Ron's normal answer to many problems (often validly). But I think in this case he is drastically cutting short the type of information you need to make explicit. It needs to be more than just business rules. It needs to include:
My test would be, Can a new hire come into your organization and with nothing more than access to your knowledge repository figure out your work vocabulary, organization structure, what different business units do, what tools are used, and how to do their job at a basic level?
But having this information captured in an explicit form (preferably structured and searchable) isn't just of value for business continuity and ensuring critical knowledge doesn't walk out the door with departing employees; it's of tremendous value for projects. This information helps with scoping a project, acts as a continuously updated "current state" of the organization that can be leveraged, and allows critical subject matter experts to only have to devote project time for difficult-to-answer questions that require greater expertise.
In my experience (and yours may differ) the time spent by the project team gathering, synthesizing, and analyzing this information is among the most critical efforts of the project as well as being among the most likely to be cut short or skipped in an effort to deliver something tangible
or get going
or show progress
. Not doing this well or at all is in my experience the single greatest cause of scope creep, missed requirements, and missing stakeholders.
Unfortunately, creating and maintaining an accurate business knowledge repository requires organizational commitment and constant encouragement and support from management. It can't be done as a project, or an initiative, or any other temporary activity. It has to become a constant act that is integrated into the entire organizations day-to-day activities. It requires a commitment of time and effort from ALL employee's. And that is why it is so hard to do even an initial attempt, let alone keep it up.
But if you want to improve your projects; as well as your training, onboarding, and many other activities; keep Ron's article in mind. Just make sure you look at capturing more than just business rules.
Agree. Disagree. Or have thoughts of your own to share? Please send me your feedback!