Given IT companies are generally prone to see all problems as technical and even worse sometimes push specific product offerings that are basically inappropriate, this imbalance can become a big issue.

Perhaps the most common example of this is the CRM project.

Naming a project after a software solution doesn’t bode well for a kick off, tails and dogs comes to mind!

Admittedly CRM started out in life as a Marketing philosophy but today it is pretty much synonymous with a particular type of software application.

As a Lean advocate you are trying to break down functional silos, CRM software can be a real pain.

CRM software normally focusses on the needs of the Sales / Marketing function, it simply does not have a cross functional perspective. Whilst an organisation is small this is not generally noticeable, however as the organisation grows it does become far more obvious. To cover the growing needs of the organisations there is generally a need to add more and more software and these additions generally come in a rather ad hoc manner.

If you go to the other end of the organisational scale you can see how companies such as HP (admittedly a very LARGE organisation) might have managed to end up with staggering numbers of software applications – ie. not Lean.

“At HP, for example, mergers, acquisitions and growth
over the years had resulted in a global spare parts
supply chain—which provides spare parts for HP
commercial and enterprise products repair service—
that consisted of 300 applications across 79 countries.
This was a problem—a problem common among
enterprises, says Ron Griffin, senior vice president,
global IT at HP. “Large companies often don’t get rid
of legacy systems when they introduce new systems,”
he observes. “They tend to pile IT layers on top of
each other.”

Three recommendations spring to mind.

1. What are your goals in non IT Solution terms? Do you really need software? Might there be none IT alternatives that achieve the goals you want to reach?
2. IF you do think software is the best route, have you considered alternatives that are less silo’d, ones that offer a more holistic view of the organisation?
3. If (sorry,when) you decide to change your systems, clear out legacy systems, even though this is realllllly hard.

Many of these conversations have taken place when they have been tasked with helping define requirements (RD) for upcoming IT projects.

One common concern is about the decisions being made by the head of IT (ie. someone who is not generally well versed in Lean Thinking).

Generally the approach turns out to be a variant of the one outlined below

1. Define stakeholders
2. Define purpose
3. Define processes that support the above purpose
4. Define requirements
5. Pass the resulting requirements catalogue over to the technical guys so they can define / cost a solution.

I generally argue this is flawed in that I feel there are three things that Lean IT in a service environment needs to take into account

1. Respect for People
2. Continuous Improvement (CI)
3. Understanding of Variance

Then I tried to cross reference these three concerns against each other to see if the trad BA approach worked.

For me there was clearly there is a mismatch at stage 2.

The normal RD approach outlined above only maps current processes (even if there is a bit of a re-engineering going on during this mapping period). It doesn’t say much about the future need for agility to support CI over the long run. Fundamental issue.

Secondly, “respect for people” is all about the importance of delegating (not dumping) responsibility for change as far down the organisation as is possible. Problem solving needs to be developed as far down the org. as is possible however the IT system also needs to support this approach. OK most Business Analysts will spend some time on ‘non functional’ requirements, however I have yet to see a real trend towards empowering business users, without which CI stalls as change requests end up in a huge stack in someone’s in tray in IT.

Thirdly, variance in service sectors cannot be eliminated by defining processes to anything like the same degree as it can in say manufacturing. Customers are an integral part of the process. There is a very real danger that too great a focus on increasing process efficiency will dominate discussions and undermine longer term effectiveness.
In IT there is always a trade off between short term efficiency and long term effectiveness / agility.

For IT to become Lean you need to think of the future as much as the present.

Perhaps the mostly widely used Lean problem solving approach is A3 Thinking, an approach which generally reflects the Deming or PDCA cycle.

But there is a problem when using the A3 approach in complex problem situations, cause and effect are not easily identified.

Root cause analysis within the A3 approach attempts to tackle the “proximate / ultimate” cause issue but in complex problem situations there can be a plethora of potential causes for any given problem and some of these can only be eliminated after careful consideration.

After this first round of eliminations you can still be left with several contenders and you always need to bear in mind that complex problems can be “multivariate”; ie. no one cause on its own may account for the problem.

Equally there can be “confounder variables”, variables that lurk unseen.

Getting a true understanding of what has caused a complex problem can be really difficult and time consuming.

To help speed up this process of elimination we have been working on a tool  that allows you to chose any number of “activities” (ie. potential causes) and compare these against any number of longitudinal / timeline graphs (ie. problems) to try to gain meaningful insights.

For us the difficulty was in ensuring the timelines of all these numerous graphs were in sync particularly given that users generally want to be able to drilling in and out to gain clarity.

It doesn’t solve all the problems but it does allow you to quickly remove a huge number of spurious correlations!

The image above is from a successful day session with an IT Department that was struggling to understand what were the main causes of instability in there platform.

The advent of the web however threw a rather large spanner in the works for the leading players in this field (Microsoft etc.) and we saw the meteoric rise of new players such as Google, players who saw the web as the future.

But now Apple has changed the game again. At the moment most apps are little more than toys. However this is just the beginning.

The move from Trad to Web based IT (Asp, SaaS, Cloud etc.)  marked a shift from distributed computing to a far more centralised version. One based around central web servers.

The advantages of this were massive but the one huge headache was the need to be able to access the internet before you could get to your systems.

Apps tackle this big issue by returning some of the location of computing back to a local device, normally either a smartphone or tablet.

In the consumer world this is has not been a problem but the interesting thing will be how long it takes for enterprise software providers to acknowledge this shift and rejig their products to take advantage of this newly emerging situation.

What does this mean for Lean IT.

Well firstly do not dismiss this new trend just because it looks very consumerist.

Check to see whether your Cloud providers have taken this shift on board. Look for agile software that has a central web based core but that allows offline access via Smartphones etc.

So when we look in our crystal ball, what high level trends do we think will dominate the Lean / IT debate over the next decade?

Well, we expect three related issues will come to the fore

• Short term: the friction that exisits between traditional IT and business will increasingly come to a head
• Medium term: Lean organisations will increasingly be looking for their organisational learning to drive IT
• Long term: IT will evolve and no longer be seen as a brick wall that blocks continuous improvement (Lean CI)

In order for this to happen, a number of concepts will need to be re-evaluated by businesses.

Growing impatience with traditional IT amongst business users

In the early years of IT’s development huge strides where made in automating very high volume repetitive processes. Certain sectors (Banking, Insurance, Retail etc) lead the way and many other businesses took note of the gains being made in these organisations.

Unfortunately by the late 80s IT became increasingly oversold. Applications that targeted less predictable areas of business and smaller organisations began to gain a foot hold, often replacing simple tools such as spreadsheets with far more comprehensive “solutions”. This at a time when the West also began to discover Lean and its underpinning logic that the entire organisation needs to continuous strive to improve performance.

A growing number of people began to question the ROI on IT investments, and frustration set in as business users began to find their software often failed to match their original needs or grow with the organisation and the changing demands of the market.

This frustration is one every IT professional is today aware of. In organisations with legacy systems from this period, often up to 90% of IT budgets will go on maintaining these old systems, leaving ever decreasing amounts of time and resource for new strategic developments.

We believe that for many this frustration will increase. Updating old IT systems is often the equivalent of asking an architect to move a building an inch to one side!

Increasing desire for organisational learning to drive IT

At the same time as legacy systems are causing so much frustration we believe organisations are no longer as accepting of the notion of there being “one best way” to perform many of their processes. In fact there is a growing belief that as an organisation grows or evolves this learning experience should be reflected in their IT systems. Most packaged software therefore becomes a real problem.

IT will no longer be the brick wall that blocks continuous improvement (Lean CI)

All is not doom and gloom however.

We believe their that over the last 5 years huge amounts of effort has gone in on within the IT world to try to change the fundamentally monolithic nature of software applications. Agility has become the core concern for software development houses. This trend started a while back with a group of developers working on new ways to better understand the needs of clients and respond to the changes they required during production. A smaller group of developers (ourselves included) however have felt this is just the beginning.

Customers want the software they buy to be able to be changeable after production has finished and they have got it up and running in their organisation.This agile class of software, largely delivered through the web as a service (rather than installed in the clients site) has come of age.

One size never really fitted all organisations. The effort to try and make it do so was always prone to failure (think of the architect mentioned above). Even worse, many solutions never fitted all.

“Post Production” agility is coming of age. Adoption will gather pace as both business users and IT departments come to understand the trade off between agility and efficiency. In the near future software will no longer block change but actively support, even encourage it!

Growing levels of IT knowledge amongst non IT staff and a matching ability and desire by business users to take informed ownership of the direction their systems development take means the future looks bright.

The above video and post is a basic introduction to Lean IT and agileBase. If you find it interesting, keep an eye out, we’ll be recording a library of videos investigating more on Lean theory and IT application over the next few weeks, including rundowns on some of the big hitting professors’ and visionaries’ work.

If you find our logic flawed why not let us know!

Finally, we’re looking to expand agileBase into new markets – if you work in a sector or industry we don’t yet cover, let me know at cliff@agilebase.co.uk. We’re offering free setup to a limited number of such users.

Part of this pilot event was about partnering. We’re very keen on developing a partner network having always found this a great way to do business. The bare bones of our technology partner offering is:

• a free account for partner use. A really useful way for partners get to learn about aB (or just go ahead & use)
• 50% discount on our direct licensing and hosting charges for client accounts
• as much help and support as we can give
• support in pitching for larger contracts that involve aB

We will be developing this offering  further in the near future and approaching those we feel might enhance our current partner network. If you are into Lean and have a good grasp of IT (business analysis etc) why not give us a ring on 07974 145491 / 0845 4561810 or email cliff@gtwm.co.uk

Perhaps the most important difference is that in the service sector consumer demand cannot be easily anticipated / managed. My brother has a few beach cafes and when the sun comes out demand absolutely rockets. Other service organisations may not experience quite the same level of fluctuations in demand but most will experience massively higher levels of fluctuation than those organisations in the manufacturing sector, the heartland of traditional Lean.

What is less clear is whether the Lean community understands small and medium sized organisations (SME’s).

Most authors / thought leaders downplay or ignore any differences, whilst others seem to believe that SME’s have closer ties with their customers and that this magically means they are more Lean. I assume most medieval craftsmen would have had a very intimate knowledge of their clients but whether they were Lean is another thing all together!

So what are the fundamental differences?

Changes in the business environment effect both large and small alike. But SME’s are different in that their very survival relies on their business agility. In the beginning there is very little “business as usual” to pay the bills and thus a far greater need to vigorously chase opportunities even if they are completely outside the areas of business in which the organisation original expected to operate.

What does this mean for IT?  And what would a Lean IT strategy look like for SME’s?

I believe it would be very different from the one I see when working with SME’s at this point in time. Currently you tend to find a mix of light weight tools (Excel / Word etc) from the start and later on a few software applications (Accounts packages / CRM etc) begin to become visible.

Unfortunately for any strategic approach to IT, as the organisation grows they rarely do so in a way that was anticipated. When software purchases are made they seem likely to fit the bill, but because of the need for radical changes of business direction just to survive, smaller organisations rarely seem to get the expected ROI from these early purchases.

What is even worse is that these systems rarely get jettisoned. One sees the beginnings of a problem that plagues larger organisations, the proliferation of IT systems that don’t really meet current needs, and yet that are too embedded in the organisation to be removed. The dreaded legacy system issue!

IT does not have to be this way. Simply put agility has to be valued over “best practice” and “efficiency”.

If you intend to grow quickly this is doubly true.

There have been some really interesting ideas coming out of this area but I always need to test ideas before I can accept them wholeheartedly. So, in the background a colleague of mine (Oliver) and I have spent quite a lot of time capturing this learning into a product (agileBase) and using this as a real life test bed with organisations of various sizes.

I have found two things increasingly frustrating.

• the focus of the debate, which seems largely to be about mega organisations even though these organisational only make up a tiny proportion of the entire organisational population, can be very misleading.
• IT is hardly understood by Lean Service Sector gurus.

I believe there is something fundamentally wrong in most of the advice currently out there and I hope this blog will provide an alternative view of Lean IT specifically for those working in small and medium sized organisations (SME’s), and in particular for those that are experiencing rapid change.

Lean is important, IT is important, SME’s are important!