Lean & IT

Forrester Research recently held several “jam sessions” the first of which was one that focused on the topic of creating a leaner IT, and has followed it up with several discussions on lean, declaring, “lean is ‘in’ right now.”  This scares me.  Not because the folks at Forrester are wrong, precisely the opposite.  They are right on in declaring that lean is a mindset and culture.  What scares me is how organizations and consultants will respond to this declaration.

Now, I am a huge proponent of Lean, having been involved with it my entire career, but organizations need to tread carefully when embracing Lean thinking.   Many will start with declaring they are starting a new ‘lean initiative’ and will hold kaizen events, use Value Stream Mapping, send people to training, study the Toyota Production System, and, yes, they will get results (this stuff DOES work).  After a while, however, they will start to stagnate.  The ‘lean initiative’ will start to seem stale, and will eventually wither on the vine, becoming yet another initiative that failed to sustain and meet expectations.

Why do they fail?  Because they did not implement Lean, they implemented the TOOLS of Lean.  Kaizen is a tool, Value Stream Mapping is a tool – in and of themselves, they are not Lean.  Lean is a culture of the continuous pursuit of the elimination of waste in everything the organization does.  Toyota does not care that companies (even competitors) come study their production systems, because they know that by the time the competitor is able to implement what they observed, Toyota will have moved on – that is the way their corporate culture works.  Toyota does not have a ‘Lean initiative.’ Toyota does not ‘do’ Lean, they ‘are’ Lean.  It’s just the way they do business.

Implementing the tools of Lean will get you results, and will help move you toward becoming a Lean organization, but Lean is bigger than the tools.

So, as IT organizations move to embrace Lean thinking, the question becomes, “Are you going to ‘do’, Lean, or are you going to ‘BE’ Lean?”

Glenn Whitfield

Advertisements

IT Project or Business Project?

100% of IT projects fail.

OK, maybe it’s not all of them, but everyone can agree the percentage is larger than anyone connected with the process would want to see.  While there has been much research on this, with case studies, methodologies and frameworks developed to help an organization be successful at implementing a project; one reason that often goes unnoticed is how the project is defined from the very beginning.  Is it really an IT project, or is it a Business Project that involves IT?

Now, before you go off and say, “Well, every project is a business project,” let’s set up some parameters for this discussion.  We’ll use the traditional paradigm in an organization that IT is a department, and anything that involves technology will be led by the IT department (PMO, etc.).

The way it traditionally works is the organization decides it wants to install a new system to help it improve a particular Business area (doesn’t matter if it was initiated by IT or the Business area), then, once approved, a project manager from IT is assigned to lead the project.  There is probably a “champion” from the Business area (likely a VP), and there may, or may not be dedicated resources allocated from the Business area.  If a resource is dedicated, it’s usually someone who “has the time.”  So, off the organization goes with its latest “IT Project.”  The IT PMO leader reports out to the “steering committee” that has been set up to oversee all IT Projects.  As time goes by, hiccups happen, setbacks occur, and the IT project manager is answering to all of the issues the project is having.  When it is “finally” implemented, it doesn’t work as expected, and is usually deemed another failure (the degree of which varies).  Who catches the ire of management, well, IT of course.  After all, they were the ones who were responsible to manage and implement the project.  So, IT leadership huddles up and tries to come up with a new project management approach, or technique to manage their “IT Projects.”  And the cycle repeats again and again and again.

Why does this happen?  Because we define every project that deals with technology as an IT project, and then try to manage and lead it accordingly.  And we fail.  So, what should we do?  The first step is to determine if we have an IT project, or a Business Project that involves technology.  This is done by determining who will get the greatest benefit or impact from implementing the project as the organization measures itself.  If the organization is installing a new finance system, then although the whole company can benefit from this, the greatest impact on the business processes is probably in the finance department.  Therefore, someone from the Finance team should lead the project day to day (with project management support from IT).  Likewise, if it’s a server virtualization project, then, although virtualization will benefit the entire organization, the business process impact is in the IT department; so this should be led by IT.

To improve your chances of success, identify the true project owner – who is impacted most, and who gets the most benefit, then select the project leader from that area.  This is a great opportunity for an up and coming leader to show their stuff!  Give them the proper support (like PM from IT experts) and authority they need, and let them get to work.

You will be amazed at the results.

IT's Responsibility to the Business

 

When implementing a technology project, whether major or relatively minor, it is easy to forget the value and insight IT leaders and project managers can bring to the process being impacted.  This is something that is often forgotten not only by business leaders, but by IT leaders as well.  Much of this can be attributed to the “that’s the way we’ve always done it” attitude.  This must STOP!

As stated in previous posts, IT is in the unique position to see the impact of changes across the organization, not just in the primary area impacted.  But, while it’s one thing to see it, it’s another to actually DO something about it.  How often does this happen?  A business leader makes a decision.  The IT staff follows orders and provides the IT solution that does what the business leader said he wanted – all the while wondering why such a “bonehead” decision was made due to the implications on the business further down the process.  The thoughts often go like this, “Hey business leader, you asked for a solution; I gave you what you asked for.  Not my problem if there were other issues because of your decision.  That’s not part of my job.”  IT leaders will cringe at the thought of their staffs thinking this way, and will swear up and down it doesn’t happen in their shop – but it happens, more than we would like to know.

Here’s a way to avoid it.  When I was working with a $1 Billion regional healthcare organization with multiple IT systems, the IT project manager came to me with a problem (one core system solves the problem, but that’s another issue).  The organization wanted to launch a branch of the rehab hospital inside of one of the existing acute care hospitals.  His job was to get the IT systems up and running.  They had just had a meeting where the acute care hospital president stated he wanted the rehab branch on the same IT system as his hospital.  To him, it made sense to have all the patient information on his system (primarily for accounting purposes), since the rehab branch was in his hospital.  The problem was, as the project manager explained to me, that the rehab hospital and all its existing branches were on a different system, and the physical therapists staffing the branch could come from any of the branches, so they would have to learn and know 2 core systems.  Also, it was planned that patients would transfer from the rehab branch at the acute hospital to other less specialized branches as their condition improved, creating duplicate entries when the patient went to another branch.  And, to top it off, the additional work to write and test the multiple interfaces put the project’s timing at risk.  But, the president said he wanted the rehab branch on his system, so that’s the direction the team was taking.  I asked a simple question, “Does he understand the consequences of his decision?  Did anyone explain them to him?”  The answer was, “No, he’s the president.”  My advice, “Then you need to.  He’s a reasonable person, lay it out and make sure he is informed.”  And he did.  The president realized the implications of his decision, and quickly reversed it, keeping in mind what was best for the organization as a whole. 

 When a business leader makes a decision about the direction of a project, and you know there will be unintended consequences, speak up.  No, not in front of everyone, but in a one-on-one session (always remember to use tact – never intentionally, or unintentionally, embarrass the boss in front of others).  Collect the information and what you believe to be the consequences of the decision and present them in a logical, concise manner (keep your boss informed as well – whether or not your boss attends will depend on your organization’s culture).  Then if the business leader still makes the same decision, at least they have done so with full knowledge of the consequences, and you have done all you can do to keep them informed.  Then, you may sleep better at night…. or want to update your resume.