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 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!

Tuesday, March 11, 2014

Getting a Grip on Governance

As a programme and project manager, particularly in large matrix organisations, one of the things that used to drive me mad was the lack of joined up governance for projects. I know I'm not alone. Whenever I've been involved in organisations improvement initiatives, this is a regular bugbear across delivery.

Project managers, who are often juggling multiple projects, have to undertake a myriad of reviews, complete multiple status reports, and submit to random, often unsolicited, data requests, and run the gamut of Delivery and Quality Assurance audits. In the worst cases I've seen, an individual PMs can lose as many as 5 days a month just providing data and sitting in review meetings, often saying the same things to different groups of people (and sometimes exactly the same people!).

Now, I'm not advocating that anyone should stop performing reviews or monitoring project status. That would be a violation of lots of things I believe in, and probably commercially suicidal. But I do believe that organisations can get a lot smarter in they way they perform their governance, freeing up people's time, reducing the burden on projects, and adding genuine value to the organisation as a whole.

In a many typical organisations the project is answerable to external and internally facing governance. The client or business wants to know how their money is being spent and when they can expect delivery, and the delivery organisation needs to understand how to manage its people, IT assets and other resources. These aren't unreasonable expectations.

What's unreasonable is when the balance shifts from a need for information to help run the business to a culture of interference, where indirect stakeholders start demanding their pound of flesh. Where bean counters get notifications from monitoring systems and demand answers as to why variances are exceeded and expect solutions to be implemented by yesterday.

Quality boards and risk review boards are set-up in addition to the weekly, monthly and quarterly status review boards. Red and Amber projects find they are spending more time explaining their status than being able to fix it.
Ultimately, the project managers spend their days repeating the same things to the same people time and time again. And the majority of the people listening are not actually in a position to do anything with the things they are told, let alone provide help to the beleaguered projects.

The sticks are all sharpened ready for the kill, but there isn't a carrot in sight.

When an organisation has a systemic problem with delivery it seems that the usual way they go about fixing it is to add more and more layers of governance. It's as if talking about it often enough will make the problems go away. A smarter fix might be to review the entire governance process, streamline it and only involve people who can provide assistance and solutions, rather than add to the problem.

Joined up governance means looking at how automated monitoring systems can be used intelligently and incorporated into standard reviews. It means looking at the people who need to be involved in those reviews, what preparation needs to be done (in my experience people just turn up and fire high level standard questions at the PM), and what the expected outcomes are going to be (a completed review checklist is not a satisfactory outcome!).

This is really an ideal role for a pro-active PMO, that acts as a conduit between the relevant stakeholders and the project. Indirect stakeholders (should there still be any need for them) should be able to get information from the PMO rather than the PM. (If the relationship between the PM and the PMO becomes imbalanced, e.g. when the PMO starts to become a self serving force, this must be redressed - see my 2008 article Project Management Office - Master or Servant?).

As part of the change to governance, it's an ideal time to review the measurement systems in place. Projects are often challenged as to why data differs across different systems. The better question is why data is being captured in multiple systems in the first place as it clearly introduces scope for error - see my 2010 post When Measurement Programmes Go Viral.

Project and programme oversight shouldn't be rocket science yet many organisations have governance systems that would not look out of place in mission control. As spring starts to take hold this year maybe it's time to take a good look at your existing governance and see where it can be cleaned up, simplified and ultimately become a valuable tool rather than a weapon to be deployed against project teams doing their best to deliver real value to the business.

Friday, February 28, 2014

7 Deadly Sins of Process Improvement/Change - #7 Extravagance

My final deadliest sin is that of extravagance. Extravagance is not confined to process improvement, but for many years was something of a feature of the IT industry. Extravagance has two meanings, and both are relevant in this post. The first definition refers to the lack of restraint in spending money or use of resources. The second refers to the excessive use of elaborateness in style, speech or action. Both have a similar impact on resources and money, and both can be resolved through similar management techniques.

Massive improvement programmes are still popular in large organisations. Huge budgets are set aside, an army of internal and external consultants is assembled and the senior management talk about nothing else for months. It's a matter of all hands on deck and a marketing campaign is launched resembling Kitchener's call to arms in 1914. This seems particularly true for such activities as Obtaining CMMI Level 3 or becoming ISO 9000 certified, but more recently for Becoming Agile or Lean.

Behind the frenzy of activities, old timers quietly mutter about the 'last great improvement programme' and the fact that this one won't bring any significant change after making their lives hell for the next two years. Newer members of staff, especially managers, begin to dismantle the good things that did come about from the last great change, in favour of their own pet projects and generally the whole organisation becomes a circus where each and every one of my previous deadly sins is performed in some office or corridor of power.

The problem with extravagance is that the focus of the change moves from being for the benefit of the business and shifts towards feeding egos and personal agendas.

Extravagance isn't restricted to large endeavours either. Small improvement projects can easily lose their scope and expand to fill the number of hours in the day and gobble up limited improvement dollars and staff patience.


Keep It Simple

The old adages are always the best ones. The larger the scope of an improvement or change programme, the greater the risk of it stepping on its own toes as one part of the programme starts undoing the good being done somewhere else - for example a project management status report being streamlined in the PM work stream whilst the management review process is being extended in the Governance work stream. Sub-optimisation is the greatest enemy of large initiatives which fail to take a holistic approach and will cancel out improvement benefits if you aren't careful.

Remember Your Audience

Most people have a limited capacity for change in any time period and over elaboration of an improvement programme will be subject to the law of diminishing returns. If your staff begin to show signs of change fatigue you need to scale back on your ambitions - but better still, show restraint in the first place and package changes into small enough packages that can be managed and implemented without overwhelming people.

Beware 'Just one more thing'

It may have worked brilliantly for Steve Jobs as a theatrical tool at Apple Keynotes but it has no place in an improvement programme. In Jobs' case the one more thing may have thrown the crowd into a frenzy, but in an improvement programme it may well be the straw that breaks the camel's back. Don't go on cramming more and more into an improvement initiative. Prioritise and move less important opportunities to later phases.

Laws to Overcome Extravagance

1st Law - Keep It Simple

2nd Law - Organisations, teams and individuals can only deal with a certain amount of simultaneous change

3rd Law - Beware the executive who begs "Indulge me" with an additional requirement after all the plans are in place