Another post on the nuts and bolts of putting together business documents.
A charter or terms of reference (TOR) document outlines a basis for the exercise of authority by a group. The group may be an existing team, or specially formed for the purposes of fulfilling the charter or TOR.
Knowledge Management is a discipline often accused of running programs whose success is essentially unmeasureable. This then leads to accusations of "not delivering value", and sometimes even the scaling down or elimination of KM programs within the organisation as another "failure".
Tom Davenport makes an excellent point in his most recent post about the challenges of decision making:
We have lost much of the connection between the supply of information and the demand for it in decision-making. Despite the fact that companies often justify IT projects on the basis of better decisions, there is seldom a direct tie between the information a particular system produces and the decisions that are supposed to be based on it.
This article from FastCompany.com had my head nodding. In reality, most of them boil down to one of three categories:
Read the whole list. It's worth a look.
Okay, so you've written your strategy document and got it all signed off by management. Now the hard work begins.
It is likely that each of the goals outlined in your strategy will require a number of initiatives that move the organisation towards that goal. Each initiative will need to be described in sufficient detail that management feels comfortable that the initiative is both (a) going to work and (b) be aligned with the goal or goals in question.
Writing the case for a strategic initiative is just like a cost/benefit analysis, but applied to the long-term. They are normally expressed in terms of drivers and benefits.
They have re-organised the page on me, but I'm pretty sure that 12manage is the same web site that I've found, lost, found, lost and finally found again.
Essentially, it's a resource listing just about every management tool, technique, fad, and jargon under the sun. So if you've ever wanted to learn more about Business Process Re-engineering or Six Sigma, this is the place to start.
An abbreviated version of the list from Bob Lewis's excellent column, Keep the Joint Running:
| Goals | The goals no longer make business sense |
| Scope | The scope keeps expanding |
| Plan | Tasks are "stuck" at 80%; tasks take over a month; or no task planning at all! |
| Optimism | Project manager "hopes" everything is going well |
| No demo | Can't produce a working demo by the appropriate point in the project |
| Testing | Continuous testing and bug lists aren't shrinking |
| Team | The team members want the project killed |
Strategy documents need to outline two key things -- the objectives of the strategy, and the goals which are necessary to achieve these objectives.
Bob Lewis explained the difference between objectives and goals to me this way:
[An] objective [is] the point of it all, described from the perspective of business benefit. So if what's being proposed is a so-called CRM system (customer relationship management) the objective might be to increase revenue and decrease the cost of sales.
["Goals" are the] changes that will occur that will result in the benefits described as the objective. For the CRM effort, the goals might include designing a new sales process, selecting, configuring and implementing software that will support the process, developing and delivering a sales training program, and so on.
Or to put it another way, one type of consultant explains the "what?", the second manages the "how?", and the third diagnoses the "why?".
My favourite saying about organizational effectiveness is:
"To optimize the whole you have to suboptimize the parts."
I've stolen this from Bob Lewis and although it sounds trite it covers a whole lot of assertions like:
