In many years of improving companies of many types, I have always found that alignment of the supporting technology platforms was critical to implement sustainable change. Yet, many Lean people I meet are really hostile toward systems. I empathize with the general sentiment. Many systems do seem to fight the Lean practices we hope to achieve. The problem is that systems are essential to run big companies. To make things worse, the Lean staff from the manufacturing side of the business just do not describe their needs in ways that the IT team can understand. Even with the best intentions on both sides, there is frequently a huge gap of understanding which makes matters worse.
I hope to help bridge this gap. In searching the web for resources on this topic, I found very little. There was an occasional article on a Lean blog, but these are all too often sandwiched between articles lashing out at how horrible systems are. It is not any better on the IT side. There are some great groups dedicated to Lean and Agile software development. These tend to focus on just the software development process as opposed to how to support Lean business practices across the enterprise.
I have spent most of my career implementing systems and Lean (usually ERPs). Yes, there are definite alignment problems, but by no means do ERPs prevent Lean practices. No system ever mandated build to forecast as the only manufacturing strategy. Likewise, supporting functions have ample opportunities to implement Lean within the confines of an ERP.
Thanks for stopping by and please come back (and offer your commentary). We are just building this up now and eventually plan a practitioner forum to improve the information exchange in this space.
I think that business cases are potentially the most misused business management tool in existence. How many times have you or your team created one “because we have to.” And how many times did you start with a result and back into the details? Have you ever created a business case which you privately called “bogus” to your confidants. Don’t get me wrong, business cases are critical tools to support decisions. Often the precision is overstated, but the process of uncovering costs and benefits can dramatically improve the ability of a company to manage an investment. For me, the questions is how much is enough and where do you focus your time?
Business Case Rant
The extremes are easy to spot. If you are investing a large amount of capital, a business case is frankly critical. Likewise, if you are asking a subordinate to develop a new template which requires 1 hour of work, you clearly are not going to develop a business case for this. It is all of the other activities in between where the question lies. I think that there are three factors which have driven misuse of business cases:
- Weak business leadership afraid to make a decision: I hate to say it, but this happens frequently. I see business leaders using extended business case analysis to build their courage to make a decision. In these cases, the extended duration does not lead to a deeper understanding of costs and benefits, but instead more complicated spreadsheets that actually cloud the key performance drivers.
- Corporate environments where direction changes are frequent and make staying the course on investments difficult: Where the first item is focused on the decision maker, this item is focused on the company. Many pragmatic leaders in these environments have found it necessary to spend significant time justifying their programs. I have to acknowledge that in some environments, this becomes necessary overhead to drive corporate change. As a leader, you have to critically assess whether you are in the first category or this category.
- The curse of 500 business cases: I am passionate about continuous improvement. I have spent much of my career leading these activities. However, Six Sigma programs in particular can become very bureaucratic, with the business case often at the heart of this. Spending 10% of the total effort time on a big project thinking about costs and benefits and then updating this view as analysis occurs is a very smart thing. It is crazy to spend 50% of the work time on a small departmental project fusing about the business case, especially where there is no investment beyond the effort time to implement a process change. The Japanese have a term for this, over-measurement.
How to Know if You Are Succeeding
There is a significant amount of business judgment required in finding the right level of business case justification. I also recognize that the people writing business cases are not the evaluators and sometimes are just stuck with a sub-optimal process. You can control whether the process actually helps you manage the change better. This is completely in your control and might actually mean that additional evaluation is required beyond a static template offered by corporate finance. Ask yourself if the business case and the process of creating it has yielded the following.
- Deeper understanding of costs and benefits
- Major items understood in more detail
- New costs and benefits emerge which were not known during scoping
- Sensitivity of costs and benefits understood, at least conceptually (do not need an agonizing sensitivity analysis to accomplish this)
- Key risks can by stated concisely
- Team better understands scope and how it maps to both costs and benefits
- Key costs and benefits can be measured simply and statused without huge work efforts
- Team comes out of the process with greater confidence in the decision and energized to start work
I think that single thing to take away from this post is to remember that business cases create outcomes beyond a spreadsheet and that it is completely in your control to achieve these outcomes, even if you have a dysfunctional business case process inflicted on you by someone else.