- Whether to mention a pregnancy in a job interview
- A possible meeting protocol
- What are an end-user's responsibilities?
- Another take on opening PCs, or not
- Getting some process going
- Selling a more open environment to management
- Running an effective meeting
- Licensing rules for virtual machines
- The ROI of metrics
- Legal challenges to virtual machines
January 28, 2008 | Comments: (0)
Balancing strategic and tactical improvements
Dear Bob ...
My current boss has asked me to undertake an extensive review of organizational information practices, with an eye to (1) understanding how the business works, and (2) seeing what can be done to improve our practices.
So far, I've documented about 100 requests and suggestions for improvements from staff in the various business units, and to my mind, the next obvious step is to sit down, prioritize which tasks are most important, and just start addressing them.
Instead, my boss wants me to identify broader strategies, establish business drivers and benefits of pursuing these strategies, and them submit these to the next management level up for approval.
To my mind, this smacks of retrospective justification. If there are perceived problems out there, why do we need a strategy before we can fix them?
Or is this a case of me seeing the trees instead of the forest?
- Prioritizer
Dear Prioritizer ...
I think you and your boss are each about half right.
One reason to not just "do the list" is that even if every idea for improvement is a good idea taken in isolation, it's doubtful they will all mesh harmoniously if you're able to find a way to put them all into practice.
One of the basic, unexpected principles of design is that in order to optimize the whole you have to sub-optimize the parts. If you have a list of one hundred improvements it's just about certain that many of them ... probably most of them ... have a local focus. That means they are intended to improve a part, which will sometimes happen at the expense of the whole.
If this point isn't clear, read "Optimizing the organization," (Keep the Joint Running, 10/27/2003).
The other big reason for not just diving into the list is that when a company allocates too much of its available staff to work on a large list of small stuff, there might not be enough left to take care of what's most important.
One reason you are right is the Edison Ratio: Genius (and success in general) comes from one percent inspiration and ninety-nine percent perspiration. In context it means having big, strategic ideas is often less important than sweating the details.
The other reason you are right is that small, focused efforts have little risk of failure and deliver business value quickly. It's the big strategic ones that fail often and don't deliver any value for long periods of time.
There's a way out of this collision of incompatible rightnesses. It is (don't sneer!) a magic quadrant analysis.
The vertical axis represents cost and risk - the reasons why not. The horizontal axis represents benefit and impact - the reasons to proceed. Here's how you label and handle each quadrant:
* Upper left (high cost/risk, low benefit/impact): Kill. There's no point to something that costs a lot, has a high likelihood of failure, and won't accomplish much that is useful.
* Lower left (low cost/risk, low benefit/impact): Delegate or re-scope. Most of your items probably live in this quadrant. If they really are isolated, small efforts that are local in scope, beneficial in a minor way, but won't cost much and are pretty much sure things, delegate their execution to the area they effect and forget about them. The good news about these is that they accumulate. A few thousand small, seemingly unimportant improvements turn into a big deal after awhile.
Others in the same quadrant will turn out to be linked in some way to other items either in this quadrant or others. By consolidating them, you'll eliminate redundant work, avoid incompatible outcomes in related or linked efforts, and achieve more important results. This, more or less, is what your boss is telling you to do.
* Lower right (low cost/risk, high benefit/impact): Full steam ahead. There aren't a lot of these, and they're the best of all possible worlds. You spend little, risk little, and get a lot in return. It is possible you'll have some of these on your list. If so, get them started as fast as you can.
* Upper right (high cost/risk, high benefit/impact): Select and manage. Companies can't undertake too many high-cost, high-risk, high benefit/impact initiatives at the same time. They can't - companies can't absorb that much change all at once. And, each effort of this size and scope requires significant executive oversight or they will fail. Companies have only a limited supply of executive oversight.
My best advice, then, is to find the linkages that almost certainly connect many of the items on the list, and then to package them together in the form of strategic initiatives, so that when your company implements them the results will fit together.
Find a way to delegate the rest so they are handled quietly and locally.
That gives your company the best of both worlds.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on January 28, 2008 09:56 AM
RATE THIS ARTICLE:
-

- COMMENTS
I slightly disagree with the use of a quadrant as an early step. I think the boss is right in asking for a broader perspective and in getting sign-off.
I was once doing a project with a large corporation, and everyone was focused on optimizing a web portal. No one was looking at how the project tied to shareholder value or generated worth to the company. When I had the chance to talk to executives, they didn't care one bit about the portal--they just wanted to lower costs significantly because of an upcoming issue they were aware of (and the project team was not).
When looking at improvement efforts, it is critical to really focus on what drives value, and get feedback from top management. They will sometimes have a new perspective that will entirely alter the perspective of the project leader and team.
The use of the trick the boss is proposing is a good way to have that discussion with upper mgmt.
Once their feedback and input is obtained, then the use of your quadrant makes a lot of sense.
Posted by: Brad Scheller at January 30, 2008 11:05 AMI think the quadrant is an excellent way to start, because it will help you better understand what to present, and how to frame the presentation. From a different perspective, you would look stupid starting the presentation with a project in the low benefit category. But that raises the more important question:
Do you have a clear understanding of what benefit/impact would be considered high/low? Is it measured by the pain and frustration of those on the front line? Or simply direct benefit to the bottom line? Brad, above, is definitely thinking more about the direct bottom line, and there clearly is wisdom doing so, and a time for that. But, there is also a great deal of wisdom ensuring that the people who make the bottom line happen [which isnt the executives] are able to perform well -- this directly relates to 90% perspiration. Many improvement projects that ease their pain will have a huge impact on their productivity and confidence and value in the organization. The path to the bottom line takes a bit longer, but lasts alot longer too. Cutting costs is constrained by the number zero, and the closer you get to it, the harder it is. But, there are no limits to productivity.
Anyway, reining myself back in, my point is that the magic quadrant is a great place to start, but only after you have a clear definition of benefit, impact, cost, and risk. This means you need to understand how management thinks about those things too -- find out before your presentation. The essence of your presentation to the management team is to get buy in that the criteria for prioritizing is sound and agreeable to them. If you get the criteria from them in the first place, that should be easy. From there, it may only be a small leap, but it will still be a leap, to get them to buy into the project list, based on prioritization, informed by the magic quadrant, informed by their criteria.
I didnt know it until I read Bobs response, but I have been using the magic quadrant principles for a long time. It works.
Good luck!
Posted by: George Suskalo at January 31, 2008 07:28 AMI've never heard of a quadrant analysis before -- and the Googlith will not provide...
Anyone willing to point me to a good example that explains it? I have a vague idea from reading Bobs analysis above, I mean I do the Bucket analysis, if it works, put here, if it makes the boss happy and it is easy put here, otherwise put it in the act like it doesn't exist bucket until the problem become a critical bucket.
Just a comment on your comment system, look into TAB ORDER, I swear it works in both Firefox and IE. Also, if you want to prevent spam, lets not have it for every step of the way (because lets face it, if you did it once why should you do it alway to the end of the train?), use Ajax and an inline frame for previewing the posting, OK?
Posted by: Michael White at February 7, 2008 11:05 AMI like this analysis and have used a similar method to prioritize projects, but I have one problem with Bob's version - Cost and Risk are not always necessarily correlated, and this version suggests that they will always be in the same quadrant (i.e., if it's high cost it is also high risk, or if it's high risk it's also high cost.) I can think of many examples that would be high risk but low cost, since the risk only becomes costly if the negative outcome is in fact realized.
Posted by: CAT at February 13, 2008 07:15 AM|
Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account. Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them. Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline. ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings. Order your copies today! |
TOP STORIES
Sun to clarify JavaFX planMS's dev tool service packs
HP in talks to buy EDS
Developers' role shifting
MS: XP SP3 reboots OEMs' fault
Apple: iPhone out of stock
Can Sun rejuvenate Java?
Powerset unveils Google-killer
FBI worried about Cisco gear
AMD updates quad-core Opterons
ADDITIONAL RESOURCES

- Virtualization: A Step by Step Approach to Success
- Dialing up Agility with Business Transformation
- 5 Things You Need to Know About Storage Virtualization

- Is your smaller organization ready for High Availability?
- Is system maintenance doing more harm than good?
- Virtual Test Lab Automation: Manage development infrastructure





