Friday, 24 October 2014

Change Debt - No Second Chances

In the past few years ‘Technical debt’ has become a fairly hot topic. Using the description from Wikipedia, ‘Technical debt’ is a metaphor referring to the eventual consequences of poor system design, architecture or development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.'

When I was cutting code, way back in the mid 1980’s we had the problem, there just wasn’t really a name for it. And back then, we had a different way of dealing with it. I was writing programme during one of the most volatile periods of platform change – from mainframe to PC, from MS-DOS to Windows, and from stand-alone to client-server architectures. And each time the platform changed, we did a fairly significant amount of re-architecting, re-design, refactoring and rewrites.
The modern day business drivers of time to market and reduced cycle times were less important then, especially in the niche markets that I was working in. Speed of execution, features and reliability were our main drivers. In the last job where I did still write code I was tasked with improving quality and maintainability and our efforts went a  long way to protecting us from technical debt.

I haven’t written commercial code for nearly 20 years now. But having been involved in dozens of organisational change programmes, I believe they share a similar problem to ‘Technical Debt’. For want of a better expression, I’ll refer to it as ‘Change Debt’ – which we can define as the cost of failing to adequately plan a change or making hasty or ill-considered decisions when implementing change within and across an organisation.
The key difference between Technical Debt and Change Debt is that Technical Debt creeps up on you over time and ultimately engulfs you if you do nothing about it, wheras Change Debt is more like owing money to a loan shark and will probably cause you considerable harm almost immediately.
The real problem with Change Debt is that it is often irreversible. Once you've made the critical (bad) decision (or not made it) you are largely stuck with the consequences - and not only for the lifetime of your current initiative, but potentially for future initiatives.
So, when you are planning your next change programme, take a few extra moments to think carefully about what you are doing, what and whom you are going to impact, and consider the consequences of your decisions and actions from different perspectives.
You may not get a second chance!




Tuesday, 26 August 2014

Bring Purpose and Value Back to Project Reviews

In the past 30 years I’ve attended hundreds upon hundreds of project status reviews in various capacities - sometimes as the project manager (‘victim’), more often as a general stakeholder (‘muzzled bystander’) and on a few occasions as a review lead (‘master inquisitor’). I can’t honestly remember a single instance where the review has actually proved directly useful to anyone involved. I’d go as far as to suggest that the best project status reviews were the ones that got cancelled, thereby freeing up time to do something useful instead.

But, before going any further, let’s just clarify what I mean by a project status review. I’m talking about the regular management reviews which usually take place at the month end, after the (usually equally useless) project status report has been sent out. These reviews, scheduled months in advance, generally consist of a bunch of managers and stakeholders who ask lightweight questions about the project status. Often these are the same issues that have been addressed in the project status report but which they haven’t got around to reading yet, and usually they are the same questions they asked the previous month. In the worst scenarios, the project manager must endure a series of review boards in which increasingly senior managers ask the same questions expecting some miraculous transformation of project status during the course of the review period. Some hope!

Project managers adopt different strategies to deal with the project status review. Some come armed with spreadsheets and projections and try and bluff their way through with numbers. Others overwhelm the audience by pointing fingers and blaming the suppliers, the customer, the government and anyone else in the hope of shifting attention away from themselves. Yet others simply talk, and talk, and talk in a brazen attempt to use up the allocated review time without actually revealing anything at all.

And generally the members of the review board nod and mutter and occasionally proffer words of encouragement or caution or huff and puff about the situation, but rarely take any action. It’s all part of the game. And it’s all a waste of time and energy.

Don’t think that I’m advocating that all reviews are a waste of time - only the ones that take place because “that’s what managers do”, “that’s what the process dictates”, or for whatever other forgotten or misunderstood reason. If scheduled reviews are the established norm then review leaders and participants should at least be encouraged to ask useful and more demanding questions.

This is especially true with improvement or change programmes where project costs and schedules may appear to be on-target in terms of creating deliverables, but the real hard work - actually embedding the change and winning over hearts and minds may be a million miles off the mark. For these types of projects the review leader should consider not only including the improvement programme manager but also representatives from the target organisation who are most affected by the change. Questions and discussions should be formulated around the human impacts of the change, not purely the technical and physical aspects of the project.

I’ve worked with several organisations where the focus of reviews was always on the tangible aspects of the project - the process descriptions and other work products. Projects that appeared healthy were in fact at risk because elements like the readiness of the organisation to embrace the change, how communications were being received, and expected levels of resistance to change were never being probed.

Here are a few of the more challenging questions that a review leader could be asking of their project managers to get a better steer on the reality of a project status rather than relying on a verbal rehash of the status report.
  • What has become clear since last we met? And less obvious?
  • What is the area that, if you made an improvement, would give you and others the greatest return on time, effort, and dollars invested? 
  • What is currently impossible to do that, if it were possible, would change everything? 
  • What are you trying to make happen in the next month, two months and three months? 
  • What's the most important decision you're facing? What's keeping you from making it? How can I help?
  • What topic are you hoping I won't bring up? 
  • What area under your responsibility are you most satisfied with? Least satisfied with? 
  • What part of your responsibilities are you avoiding right now? 
  • What one thing that I can do as your manager would most help this project?
Think about you the last review you participated in, and ask yourself how useful it was, how much value it added, and how you could improve the experience and outcomes for yourself, the project under review and the other participants. And then do it!

Monday, 4 August 2014

Unifying Technical Project Management with Management of Change

One of the things that successful leaders of improvement initiatives understand is that at least 80% of the effort is about managing change. It is often something that their sponsors and supervisors also understand.

So, when you pick up a book about process improvement, you’ll generally find extensive information about understanding the psychology of change, managing resistance, winning hearts and minds and communication, and all the other ‘soft’ skills that will help you succeed. You probably won’t find a huge amount of information about writing a process. (If you think about any of the CMMI reference books there are very few pages about creating a process, although to be fair you won’t find many pages about managing change either, so maybe that’s a bad example!).

In PRINCE2 a project is “a temporary organisation that is created for the purpose of delivering one or more business products according to an agreed business case”. According to PRINCE2, projects are the means by which we introduce change into an organisation. But, pick up a book on PRINCE2 project management and you’ll hardly ever find anything about managing change, other than standard scope and change request management. What you’ll usually find are all the specific technical details about project planning, monitoring and control.

If you are creating a new product or even introducing a new off-the-shelf solution within an organisation there is a significant element of change. People will probably have to adapt their way of working. They will need to understand how the new solution integrates with existing systems and processes. They will have to understand the new expectations being forced on them through the change.

Yet, in my experience, this element of the work is rarely considered as anything other than an afterthought, and technical project managers who lead these projects are often lacking the skills required to successfully implement the change. They may deliver the product, sometimes within budget and time constraints, sometimes not, but they don’t deliver an integrated and working solution to the original problem.

The result is that staff now need to spend a considerable amount of their time trying to adapt to the change without the necessary understanding, guidance, processes and tools or even the context for why the change has occurred in the first place.

When organisations begin to understand that technical project management alone cannot meet the requirements of delivering a working solution to a problem, and learn that the end users who are closest to the work are the ultimate stakeholders, projects will continue to fail to deliver against the expectations initially set for them.

Businesses need to follow the patterns set up by change practitioners whereby technical project management skills and management of change skills are interwoven throughout the project management process, and not simply bolted on when it is already too late, or worse, ignored completely.

Monday, 12 May 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!