Tuesday, August 26, 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, August 4, 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, 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.