Beyond Blinking Lights and Acronyms

Are Your Projects "LAME"? Fri 30 Mar 07

I'm a big advocate of Lean methodologies as a way to improve a company's operations and therefore I follow a number of Lean related blogs.  Jon Miller in a recent posting, Here are 4.5 Signs that Your Lean May be L.A.M.E. at Gemba Panta Rei talks about Lean is getting a unjust reputation due to poor implementations.  Miller refers to Mark Graban at the Lean Blog who coined the term L.A.M.E as "Lean As Misguidedly Executed".  In essence, the problem isn't with the concept of Lean but rather how it is implemented.

The same holds true for many of the IT related projects we work on.  Our projects start out with a lot of hope and great expectations and as time goes on people become disillusioned and disappointed with the outcome.

Are You Ready To Throw Away Your Safety Glasses? Mon 26 Mar 07

Jon Miller in his blog on Lean methodologies, Gemba Panta Rei has a very thought provoking post where he suggests Safety Glasses Are a Sign of Unsafe Processes.  Most U.S. factories require you to wear safety glasses whenever you go out on the factory floor.  The reason for this is to protect you from flying debris.  However, if you had safe processes in place, adequate machine guarding to be specific, you wouldn't have flying debris and you wouldn't need safety glasses on the factory floor anymore than you would need them in the office.

Miller goes on to explain:

The Japanese consultants I worked with always puzzled at why American and European factories had such inadequate guarding at the source of the debris. They used to say that safety glasses are a sign of unsafe processes. I think of safety glasses as an sign of a process that is far from ideal, just like inventory is a sign of a lack of flow or forklifts are a sign of disconnected processes.

It is hard to refute the logic of the argument that you wouldn't need safety glasses if you had a safe process, and yet . . .   So while all this is an interesting mental exercise what does it have to do with IT?

"Let's work the problem people." Mon 05 Feb 07

Problems.  We've all got them.  At times it seems that's all we deal with in IT.  Problems with the network, problems with a critical application, problems with the email server, and god forbid, a problem with the CEO's PC.  There is no question about it, problem solving is a big part of what IT does.  Despite this intimate familiarity with problems you shouldn't assume all your IT folks are good problem solvers.  Although our people have had technical training it doesn't always include problem solving techniques.  The good new is that since problem solving is a skill it is something that can be readily learned.

Lean IT - what comes first, technology or waste reduction? Fri 29 Dec 06

I try to make it a rule not to make a posting that simply says "Take a look at this great blog post I found".   Although I do mention other blog posts from time to time I've always tried to either add something to the discussion or give my spin on the topic.

However, today I'm making an exception.  Kent Blumberg's posting on Lean and IT today is simply quite excellent and there is really nothing more I can say to improve on it.  Although Kent did do a TrackBack to one of my earlier postings I wanted to make sure that you don't miss his message so I'm highlighting it here.

Take a look at Lean IT - what comes first, technology or waste reduction?  This is an important topic and if you have any interest in the proper usage of IT you really need to read Kent's post.

Technology Driven Productivity? Wed 20 Dec 06

I just ran across an interesting article in the December 11 issue of Fortune magazine.  In the While You Were Out column Stanley Bing in an article called "The 0% Solution" [this appears to be available only in the print editions] talks about the third quarter Department of Labor Bureau of Labor Statistics report that Third Quarter nonfarm business productivity growth was zero.  Although this has since been revised to +0.2% it doesn't detract from Bing's point.

In this column Bing talks about a number of things he thinks have limited productivity:

1. Too many meetings - probably no one will argue with this
2. Too many digital devices - they provide an overload of extraneous information
3. Too much Internet - it's great for research but do you spend most of your time there on YouTube?

The one on too many digital devices in particular caught my attention:

• "Too many digital devices - iPods, BlackBerrys, cellphones, all pouring extraneous crud into our noggins.  You know what's productive?  A guy with a legal pad and a pencil, locked in a padded room until his work is done."

Oh so true.  This statement highlight 2 simple but very important points. 

• First, tools are only useful if they help you get your work done.  If they don't maybe you should get rid of them. 
• Second, sometimes low-tech is a better approach than high-tech.  Don't always assume going high-tech is the better path.

This reminded of what someone once told me about the effect of the word processor on productivity.  They didn't have any hard data to back up their argument but it does sound very believable.  They stated that the advent of computerized word processing was a revolutionary breakthrough in office productivity.  With it you could now get letters, reports etc. done more quickly, make changes much easier and as it further progressed you could even do it yourself eliminating labor (anyone remember a "typing pool"?).  This is very believable and I presume someone has actually validated this with hard data.

The second part of their argument is less evident but still very believable.  They stated that as the technology of word processing improved productivity peaked and actually decreased as the software got better!  The reason for this was with the more advanced features people were spending more time on "wordsmithing" than on the actual writing.  Should I highlight this?  What about italics?  Maybe I should add color? Indent the paragraph and add bullet points?  The point of this argument is that we can let the tools and all of their features distract us from our main goal.

As the purveyors of all this feature rich technology we in IT need to carefully examine how we apply it to make sure we are actually improving and not subtly inhibiting productivity.

Bing's somewhat tongue-in-cheek article and my anecdotal observation barely scratch the surface of the relationship of IT and productivity.  Fortunately, Andrew McAfee, Associate Professor at the Harvard Business School has done a very insightful analysis as described in IT and productivity growth: it was nice while it lasted? and takes the discussion beyond the issue of IT productivity tools.  McAfee makes a strong case that IT has (and will) positively impact productivity as the effect of IT has shifted from merely speeding things up to transforming how we do things.  He states:

"My hypothesis is that IT actually is a game-changing innovation of the same magnitude and importance as electricity, the IC engine, the shipping container, etc.  As I wrote in November's Harvard Business Review, I view IT as a general purpose technology (GPT) --  an innovation so important it leads to a long-term jump in an economy's normal march of progress. "

He argues that the impact of IT is now being seeing in the growth of the segment of productivity attributed to "other contributions" rather than just working smarter with better tools (e.g. faster computers) that we have seen in the past.  A increase in computing speed no longer has a significant impact since what we have now is already more than enough in most cases.  McAfee points out that what IT does do now is to allow us to transform our routines with benefits in the form of (see his article for a full description of these):

• Specified with great precision and granularity
• Replicated and scaled up with high fidelity
• Propagated with confidence
• Deployed across a very large footprint

It is this kind of transformation effect that is showing up in the "other contributions" factor.

McAfee makes a strong and compelling case and one that I think makes a lot of sense.  You may also want to check out a review of McAfee's article by Nicholas Carr in his blog posting Productivity Paradox 2.0.

Bringing this down from a macro level to a micro discussion, what does all of this mean to us IT managers on a day-to-day basis?  I think it highlights the fact that we need to shift our focus from the tools, e.g. faster computers, upgraded software, new input devices, to the transformational impact.  This is why discussions on PC's and should we migrate to Vista are at their heart, tactical discussions.  Yes, tools are important but what you do with them is more important and what we need to do is to use them to transform, revolutionize the way work and not just make it go faster.  That's where the real productivity gains will come from.

How do you feel about this?

[I should note some irony in Bing's article where he talks about "too many digital devices" and the impact on productivity.  The footer on the article points out that you can read the latest Fortune articles downloaded to your handheld device.  No doubt they believe it will lead to increased productivity.]

The Best IT Advice I Ever Got Tue 19 Dec 06

eWeek.com recently asked several IT professionals about the best IT advice they ever got and have compiled this in an interesting slide show "The Best IT Advice I Ever Got".  Check it out, there is a lot of wisdom in these few slides.

My favorites from the eWeek.com list:

• Don't prematurely optimize. Prove something works first and then optimize, because you'll never guess where the true issues lie and will waste a lot of time in the process.
• Managing IT = 80% people, 20% technology.

Some I would have added if I had been asked

• Don't let "best" get in the way of "better". (with thanks to Bill Clark)
• People don't care how much you know until the know how much you care. (with thanks to Russ Svendsen)

Which do you like?

Is Vista Worth the Bother? Mon 18 Dec 06

I came across a rather interesting debate in eWeek.  Steven J. Vaughan-Nichols in his article Vista: Why Bother? addresses the issue of upgrading to Microsoft's new Vista operating system with a resounding opinion of "If your operating system isn't broke, why 'fix' it?"

His colleague Joe Wilcox in a posting called Vista? Yes Bother has a decidedly different opinion.  He argues that the if it isn't broke argument "reflects a sentiment I hear too often as an excuse for keeping old technologies in place--long after their real usefulness is gone."  Excuse me, - real usefulness is gone?  Just because a new technology comes out does make the old technology useless.

He states that the reason people won't upgrade is plain simple resistance to change and the aesthetics of Vista are enough to justify the change.  What foolishness.  He points out that people change cell phones and iPods frequently due to aesthetics so why not PC operating systems.  Although individual may value the aesthetics of cell phones and iPods enough to constantly change them the fact remains that your call goes through just as quickly, reception is the same, and quality hasn't changed.  So although I may be willing to pay to upgrade my own equipment I would be very surprised to see any corporation pay out money for the aesthetics alone.

After reviewing these two arguments I stick with my original opinion that I wrote shortly after Vista was released;

Although the benefits can not be quantified companies will still make the expenditure -- eventually.  The reason for this is that although for most it won't be an investment with a specific return it will become a CODB (cost of doing business) for all of us.  We will need to make the switch as other new programs are developed that require it, as new PC's with Vista and Office 2007 added to the "fleet" reach a critical mass, as we run into compatibility issues, and perhaps most importantly as we develop new applications that take advantage of the new features.  Because of this companies will make the change over time as they see these issues arise and budget time, money and resources accordingly.

Joe's article generated a lot of comments (52 comments since it was published Friday morning).  The thing I found encouraging was that most of them also saw no need to rush into upgrading to Vista.  If IT really wants to be considered part of the business we need to think like businessmen and businesswomen and stop doing things just because they are cool.

What do you think?

A Variation of the 5 Whys? - How Do You Know? Fri 01 Dec 06

One of the more popular Six Sigma techniques to get at the root cause of a problem is to ask the 5 Whys.  By repeatedly asking the probing question of why (5 is just a rule of thumb) you can probe down through the layers of symptoms to get to the root cause of the problem.  For example:

Q: Why are there scratches on the machined part?

A: The part moved slightly during machining

Q: Why did the part move?

A: It wasn't held firmly in place.

Q: Why wasn't the part held firmly in place?

A: The operator didn't engage the locking mechanism.

Q: Why didn't the operator engage the locking mechanism?

A: The lock is in a location that is difficult to get to engage.

Q: Why is the lock located that way?

That was the original location before the equipment was rearranged.

Root Cause - The locking mechanism being inconveniently/improperly located results in it not being used every time.

Solution - Re-locate the lock so it can be easily used every time.

Although this is a greatly over-simplified example I think it illustrates to power of the probing questions of why?

I bring this up because we in IT are often asked to do things such as customize the ERP program that we don't always think make sense.  Maybe it is just our lack of understanding of the business needs or maybe it a case of the user not wanting to change to a new process or acting on age-old assumptions that may or may not be still valid.

The use of probing questions can help clarify this both for IT and the business.  Sometimes the requester either acting on an assumption or in an attempt to get IT to stop questioning them, uses the "nuclear option" of saying - "Our customers want it this way".  In this case asking why may only elicit a response of "I don't know, they just do".

I recently came across 2 blog postings that discuss a different form of probing question that may be more useful than why.  In do you know? Don Blohowiak shows how instead of asking "Why?" asking the probing question of "How do you know this?" may lead to clearer results.  As he states:

If your experience is like mine, with the tiniest bit of scrutiny you may find that your colleagues are too often implying facts and reaching conclusions on the flimsiest of foundations. They do this not because they intend to mislead but because the pressures of a chronologically crunched work pace lead well-intending people into sloppy thinking. And that can lead to poor decisions and costly actions.

The point of the questioning exercise is not to “trap” or embarrass anyone. Asking, “How do you know?” is aimed at helping your associates see each situation fully — appreciating what’s known about it and what’s not.

Excellent observation.  Earlier Terry Seamon also addressed this question in Whatcha Thinkin'? where he suggested questions of:

• What do you mean?
• How do you know?
• What then?

Great questions. 

I'd like to add another question: What would happen if  . . .?  The customer wants it this way. What would happen if we didn't provide it that way?  This can help determine just how important it really is to the customer and why we feel they want it.  Who knows, maybe what they want is really something different and what they asked for was just a means to getting it.  If we provide what they really want by other means may be we don't have to fulfill the original request.

The whole point of this is that by properly using probing questions we can get to the heart of the issue.  Although neither Don nor Terry were trying to link the art of questioning to root cause analysis they implicitly knew the value of this discipline.  Fortunately they also provided some reference links.  Don recommends Dr. Marilee Adams' book Change Your Questions, Change Your Life: 7 Powerful Tools for Life and Work .  He also provides a link to his interview with her about the art of questioning. Terry recommends Living with Change the Semantics of Coping by the late Wendell Johnson.  I haven't yet had the opportunity to read either book and would love to hear your comments about them.

Do you have any examples of where the probing question technique has been helpful?

Update:Implementing Lean - Are you willing to be relentless? Wed 29 Nov 06

In an earlier post I had said "It [Lean] is not just a tool for fixing manufacturing problems.  It’s the way we do business – from the way we manufacture, to the way we purchase our materials, to the way we handle sales and even to the way we do our back office operations.  It is only when we buy into this at the emotional level will we be able to be relentless in our use of it.  And being relentless is the key."

Jon Miller's recent blog post The Toyota Way is Total Company Discipline, Partial Study is GM's Failure highlights this by discussing how Toyota and GM view Lean differently and accordingly see very different results.  There are no half-measures if you truly believe in Lean.

A Rather Interesting Debate on "Whose Business Is Process Improvement Anyway?" Mon 27 Nov 06

Kent Blumberg was kind enough to pass along a link to a story on CIO.com that has generated a rather interesting debate judging by the reader comments.  Meridith Levinson's article, Whose Business Is Process Improvement Anyway? discusses the issue of whether IT or the business unit should lead the Business Process Management (BPM) efforts.  Levinson's premise is that although it is difficult to do, CIO's can lead BPM to the benefit of the company.  She states:

CIOs who seek an active leadership role in BPM have their work cut out for them. But if they can earn the trust of the business and take charge of BPM, the payoff is big. Doing so will boost their profile and that of their IT organization. It will also facilitate their SOA plans, says Burlton, [Roger Burlton, Process Renewal Group] because process management initiatives identify the business services common across the enterprise that IT can then program and package for reuse as part of its SOA strategy. "If companies do process management properly across the board, IT can do service-oriented architecture properly," he says.

Although CIO's can lead BPM, I believe the better question is should CIO's lead BPM.  I think it is sad state of affairs if the Business Unit (BU) leaders delegate something of such significance and something that will determine their future method of operating to others.  Furthermore, (and I hope I'm reading too much into Burlton's comments) the danger is that the BPM will be designed to support an IT strategy rather the vice versa.

In his blog posting, IT Led Business Process Improvement?  Andy Dabydeen points out the success stories cited of CIO leading BPM all have non-traditional IT departments and correctly suggests that you have to evaluate the structure of your IT organization before attempting this.

Personally, I have to go with the BU as being the one that has to take the lead in and BPM initiatives.  This doesn't mean that IT isn't involved, isn't actively engaged or doesn't lead many of the activities.  What it does mean is that the BU is the one that is ultimately responsible for making sure the BPM effort succeeds and they are the ones that have to live with the results.

I liken it to building your dream house. The architect may lay out the plans, supervise the contractor and sub-contractors, and basically manage the activities on a day-to-day basis. etc. However, it is the homeowner that has ultimate control.  It is up to the homeowner to outline the vision, define the scope, review and approve the architects suggestions, fund the project and ultimately live with (or in) the results.  In terms of BPM, I see IT as the architect and the BU as the homeowner.  Both the IT/architect and the BU/homeowner "lead" albeit in different areas.  So although I feel that the BU/homeowner is the ultimate leader I can see how others feel IT is the leader.

To truly answer the author's question perhaps it comes down to a Clintonesque paraphrase: "It depends what the definition of 'leads' is".

What do you think?