Monday, May 12, 2014

Trying to "Implement" Lean? - Think Again!

This weekend, I spent a couple of hours reading Henrik Kniberg’s book “Lean from the Trenches - Managing Large Scale Projects with Kanban”. The book relates the author’s experience using Kanban on a large project for the Swedish national police authority. I always enjoy these kinds of true life experiences, but this one had some personal resonance for me because of my experience with Lean and Kanban in an organisation a few years ago.



I was contracting as a Quality Manager for a global Financial services organisation in western Europe and the software development department I was working in was selected as the pilot for a new Lean IT Management initiative. The development team consisted of a mixture of employees, contractors and in-sourced staff and numbered about 70 altogether. The development work was primarily feature based enhancements across a portfolio of products.

An external consultancy (a big six outfit) was brought in to lead the initiative (at enormous cost!) and a small group of internal employees were selected to be the navigators for the initiative. Their training consisted of a 5 day bootcamp and they were joined by the department head and another senior manager.

After the bootcamp there was a frenzy of workshops over the next couple of weeks. Team members were invited to participate in the workshops but had no input into the design activities which followed. Within four weeks a new set of operating procedures were “implemented” across the team. The consultants left and the department was left to fend for itself under the watchful eye of the navigators, who were effectively the blind leading the blind.

The new operating processes were a disaster. Key principles of Lean (not to mention basic change management principles) were ignored, and staff ended up doing twice as much overhead and admin work as before. Morale plummeted, confusion reigned and productivity went south.

Despite my role as quality manager, I was not engaged in any part of the process, and as such shared the despair of the staff. However, with good understanding and experience of Lean and Agile and as an experienced change leader I felt duty bound to try and do something to help resolve the situation.

I put together some notes and recommendations and spoke with the Lean IT initiative leader. He agreed with my observations and recommendations and we set about repairing some of the damage.

Which is where Henrik’s book starts to resonate with me. The most visible new process that was introduced was the daily stand-up meeting around a team white board. Ah - Kanban - you start thinking. Only this wasn’t a Kanban board or even a Scrum daily stand-up. This was a simply a highly visible (and time consuming) task and time tracking system for each team member which duplicated existing corporate time tracking tools and project schedules. The teams were given no understanding of the purpose or how the information would be used - they were just told that filling in task sheets and attending the meeting was mandatory. Not surprising then that there was almost complete resistance to the concept and the practice.



Over the next few weeks, I worked with the management, the project managers, the navigators and most importantly the team members to try to convert the activity into something more akin to a Kanban board, and to change the daily stand-up into something that could add genuine value to the projects rather than a dreaded inquisition of each team member. We succeeded, and the teams took more and more ownership of the activity by adapting it to each of their specific needs.

There were some real take aways for the management from this whole exercise:

  • Lean is not something that you implement - it is a set of principles and there are tools and techniques that can be used to support the objectives that you collectively wish to address
  • Trying to enforce change without involving the people who do the work will usually fail dismally and have significant repercussions 
  • Don’t use a Lean or Agile improvement opportunity to try and drive through personal management agendas - there is every chance they will backfire
  • Don’t let a consultant blindside you with an off-the-shelf blueprint for success. The chances are that it won’t fit your existing culture or mindset without significant tailoring and adaptation
It was a real eye opener for me to watch a very expensive initiative being undertaken without due diligence and with precious little respect for the basics of change management. It was also extremely satisfying to be able to help turn it around - and full credit to the management for realising their problems and to the staff who actually did eventually turn a sows ear into something resembling a silk purse!


Monday, April 28, 2014

More Thoughts On the Value Management Office

In my previous post I outlined a proposal for a Value Management Office (VMO) to oversee many of the essential business activities needed in any reasonably sized organisation but which perhaps add no or little direct value to the customer. In lean terminology this is considered as Type I Muda.

I've spent a lot of time in organisations which obsess about things that don't add any value to the customer. In fact they detract people from doing the things that do add value, and at the same time cause folk so much angst that they start to loathe the workplace and their jobs in general. In many organisations these activities are so completely out of control (think internal project status reporting as an example) that they have spawned countless functions and roles to ensure their continuity, when the reality is that almost all these things should have been culled years ago. If you introduced many of these tasks into a start-up they'd be bust before the end of the week!

The thinking behind the VMO has come about from discussions with my partner (who works in a PMO for a major Global IT organisation) and my own experiences from both the top and bottom of the corporate food chain. It  also coincides with some recent posts from Bob Marshall, writing about 'meeting folk's needs' (The Antimatter Principle). I'm sure Bob will have issues with many of my ideas, but this is my Utopian vision, not his!



By centralising many of the functions and activities which generally take place throughout the organisation it is possible to take a holistic view of them all and make some sense out of the chaos. Instead of each part of the business (and each and every manager) building cottage industries out of things that should be simple administrative tasks the VMO oversees a single set of processes that are designed to be fit for purpose across the enterprise.

One outcome of this should be to reduce the burden to the staff who so often find themselves on the receiving end of multiple demands from multiple sources for the same information, with no idea why or how that information is being used (as indeed do few of the people demanding the information in the first place).

This in turn should allow 'managers' to focus on things that really matter, like removing obstacles rather than building them, and allow staff to get on with what they are best at - designing, building and implementing products and services to the delight of their customers.

Some organisations run a "Shared Services" function, but in my experience these groups still operate largely as silos, and only have very limited scope. This is especially true in command and control centres, where 'traditional' managers are threatened with a loss of power and control, and will set up their own systems, duplicating and undermining the shared services mandate. Additionally, shared services tend to operate 'top down' dictating to the workforce rather than collaborating with them.

With regard to changes, the VMO acts as the overseer of significant organisational change. It should not decide which changes become implemented, but act as a facilitator between multiple stakeholders, and to prevent change conflicts. It does this by bringing together subject matter experts who are nominated by the stakeholders. The VMO also acts as the guardian of good practice within the business, where individuals and teams can put forward ideas which can be shared and implemented on a wider basis.

Finally the VMO should be the custodian of organisational metrics and measurement, ensuring data is collected and used for the benefit of the whole organisation and to eliminate the need for multiple random data requests from staff.

Ultimately, the success of the VMO depends on a shared understanding of its role within the organisation and how other functions, managers and staff interact with it (and each other). This demands a level of maturity and some rethinking of the role of managers within the business which many people may find hard to accept.

But Utopia isn't going to get built without some pain, and it certainly isn't going to get built overnight.









Wednesday, April 23, 2014

The PMO is Dead. Long Live the VMO (Value Management Office)!

It seems that the Project or Programme Management Office (PMO) function is 'de rigour' these days. Every search I do for Quality, Process or Change Management contracts throws up a whole bunch of PMO roles - PMO Lead, PMO Manager or PMO Analyst.

Now I've never been a PMO Manager or Lead - at least not in my official 'Job Title'. I've had much more encompassing roles, which have included most of the activities I see mentioned in these job specifications, and a whole load more. Which is probably why no-one is offering me even an interview for a PMO role...but that's another story...

I've written about PMOs in the past - often in rather unflattering terms. (Ref:PMO - Master or Servant?) Because just about all the PMOs I've encountered in recent years suffer from the same set of issues all stemming from the fact that they have either lost direction or never had a direction to lose in the first place.

I'm not even sure that the PMO name is appropriate in many cases. Because many PMOs are nothing more than management snoops and data leeches - they have become a burden to the projects rather than the supporting function they once purported to be.


The PMO isn't the only function to have fallen by the wayside. The Quality Assurance (QA) function now appears to be synonymous with Testing and is often outsourced to low cost delivery centres. Many organisations also now have a Delivery Assurance function which seems to overlap in many respects with the PMO as well as traditional Quality and Process Improvement functions but without actually delivering genuine value to the business, but acting as the compliance police, and causing additional angst to project and programmes. Many businesses now appear to be outsourcing their PMOs so they will become unseen and largely unapproachable sources of contention.

In my Utopian world I would like to see an end to the unnecessary, valueless functions (Type II Muda in lean terminology) within the organisation. I'd like to propose the Value Management Office (VMO) which has a direct reporting line to the Chief Executive with dotted reporting lines to the other C-Level executives.

The VMO is a business function, designed to oversee corporate governance, organisational change, quality, compliance and process management. The VMO is permanently staffed with a small core of Value champions to co-ordinate, act as gatekeepers and maintain continuity of the function but the ideas, requirements and solutions come from Value Action Teams from within the body of the organisation. These are virtual teams created from the people closest to the work, brought together to address real issues within their scope of expertise. This isn't a new concept - it is the way many Software Engineering Process Groups function. When objectives, roles and responsibilities and values are clearly established and shared, it is a very powerful mechanism for establishing and sustaining change in an organisation.

Above all, the VMO is a supporting function, providing genuine assistance to the wider business. VMO staff should look at every activity they are involved with and be able to clearly articulate why they are doing it, who they are doing it for, what value it brings, and whether it is genuinely a business necessity (Type I Muda or actual value add to the customer).

The VMO acts as a single conduit for all organisational change where it can evaluate the impact of change and how changes align with each other (or not) and prioritise accordingly. This helps to minimise the risk of change overwhelming the business, and the problem of multiple changes competing for the same resources.

Detractors from a central VMO approach are likely to say that this is just simply another overhead bucket with a different name. Indeed this is exactly what it could become if it is allowed to function unchecked and become another self serving and disconnected unit. Which is why it needs to be under the direct control of the highest executives within the business and why its own governance must be designed to prevent that from happening.

In future posts I'll expound on this proposition, especially about how to scale up the model to work in larger organisations. If you already have a model like this in place please share your experiences, good or bad!




Friday, March 21, 2014

7 Deadly Sins of Process Improvement - eBook Now Available

I published my first article about "7 Deadly Sins of Process Improvement" way back in February 2010. Initially the idea came about as a response to a call for papers for the SEPG conference that year. The abstract only made it to "reserve" status and sadly no-one dropped out so I put it on the back burner where it has simmered over the last four years before the final instalment was served up in February of this year.

The series has proved fairly popular over the years, at least with my hardcore followers, but it is quite hard work trying to read the whole set of posts as they are separated by other random posts. So I decided to compile the eight posts and publish them as an ebook. This is partly altruistic - to make life easier for the reader, partly self-serving - I wanted to see how easy it was to produce an eBook and get it published, and partly egotistical - nothing beats seeing your own name in print!



So 7 Deadly Sins of Process Improvement is now freely available on the iBooks Store in 51 countries. You do need a Mac or an iPad to be able to download and read this version, but I am working on creating it in other formats for non-Apple users. For now though, I am happy to send out a PDF version if you send me your email address. Drop me an email at ally@allygill.co.uk with the subject "7DS Book" and I'll send you a copy within 24 hours.

I will update the publication in the future and "subscribers" will automatically get the new version.

I hope you enjoy reading the end result as much as I enjoyed creating it. Thanks for you support!