Apr
21
Don’t Read the Books
April 21, 2006 |
If you’re trying to keep up with the latest trends in management thinking or corporate strategy, whatever you do, don’t bother reading those shelves and shelves of business books you find in every store.
Most of the ones that are any good start off as a magazine article in something like the Harvard Business Review, the Sloan Management Review, or Strategy + Business. The dirty little secret of these articles, though, is that the original article usually has all of the important ideas, and the book is just padded out with additional anecdotes or examples.
For example, there’s the book Strategy Maps. I flipped through this at the bookstore, trying to figure out what the authors intended and whether it was a useful idea. There were lots of complex diagrams and stuff, but it wasn’t clear to me what the whole thing was about. However, when I found the original article, it became instantly clear that a strategy map was a particular form of goal decomposition, with specific guidelines as to what should be addressed at each sub-goal level.
(What’s goal decomposition? I couldn’t find a good definition online, so here’s a definition from the BABoK:
Goal decomposition analyses a problem by breaking down high-level stakeholder goals into lower-level goals and measurable objectives. The purpose of goal decomposition is to focus the solution on satisfying stakeholder needs. For the purpose of decomposing goals, it is necessary to consider the goals of stakeholders who will directly interact with the solution (i.e. users) and the interests of stakeholders who will not interact with the solution but do have concerns interests or concerns that they expect the solution to satisfy. Techniques for identifying a complete list of stakeholders can be found in the Requirements Planning and Management KA.
The solution exists to assist the stakeholders to achieve their goals. The main goal may be an objectively measured target or a subjective one, but all sub-goals must be objective. A sub-goal should include objective criteria allowing stakeholders involved in the process and/or the system being designed to determine whether the goal has been accomplished.
Sub-goals (or objectives) must either be achieved by the solution or by external entities. If responsibility for the sub-goal is handed over to an actor outside the scope of the solution, the solution should be prepared to cope with the failure of that actor to fulfill the goal.
…yes, I know the clarity of this definition needs improvement. Wait for Release 1.6).
If an idea sounds good and you really need more information, buy the book. Otherwise, just read the article. The article will give you what you need to know, up front, without the padding and obfuscation designed to make it look like the most revolutionary new idea ever.
Comments
What I'm Reading- Do You really Believe in What you Do?Requirements Defined - Seilevel's Software Requirements Blog
- C.R.A.C.K. Requirements managersBetter Projects
- ‘IT has no inherent value’IT Project Failures
- Business Analysis in an Uncertain EconomyJonathan Babcock
- Why We Lost Focus on Development PracticesAgile Management Blog
- Talking about what we doRequirements Defined - Seilevel's Software Requirements Blog
- BPM is not Software EngineeringGo Flow
- 3 Big CaliberRM Gotchas And How To Fix Them Part 1Requirements Defined - Seilevel's Software Requirements Blog
- Project World and World Congress of Business Analysts (PW&WCBA)Better Projects
- Troubled ProjectsHerding Cats