Meetings - Corporate Procrastination

Hands up if you've been in a useless meeting this week. It's Friday, so I'm guessing most people reading this have probably been in several useless meetings by now. If you're very lucky your useless meetings may have been interspersed with some useful activities some which involve people other than yourself but would you call them meetings?

I could write a few paragraphs about how you could make your meetings more effective. They'd include having an agenda, an outcome, the right people invited, and having those people prepared for your meeting.

I could extend that list of good things to do in advance of your meeting with some advice on how to run your meetings more effectively. They'd include turning up on time, sticking to your agenda and purpose, keeping people focused and included, not having laptops and phones in use, and keeping brief minutes, at the very least recording any actions arising and decisions made.

But the best solution, is simply to consider the alternatives to having the meeting in the first place.

Even when scheduled in advance, every meeting you convene is going to cause someone an inconvenience, including yourself sometimes.

• Since they accepted the invitation your lead engineer may have suddenly come up with an idea to solve a problem that's been nagging around for a week and now has to break their train of thought to up sticks to attend you useless meeting
• Your product manager may have spent most of the day in useless meetings and hasn't had a break or even lunch and is becoming less and less engaged whilst thinking about his evening meal
• The marketing manager is on leave so you'll have to update her on the outcome of your meeting as soon as she gets back - so you've already scheduled another meeting for the two of you

There are dozens of valid reasons why people have something better to to than sit around talking about stuff when they could be doing useful stuff. Admittedly, the options almost always involve disturbing someone, but it's almost always better to annoy one person at a time than a whole bunch of people simultaneously. So here are some alternative options:

• Put your discussion items in an email and ask the most appropriate people to comment on them within a specified time. This at least allows the individuals to schedule their time to suit them rather than finding a mutual time that is inconvenient for everyone
• Go and talk to someone over a coffee (or pick up the phone if you're not co-located) for an informal chat when it is convenient for you both
• Save your topic for inclusion in another meeting where a suitable action can be taken on how to proceed - you might not need a full meeting to get a resolution
• Allocate a fixed time every week to discuss a bunch of little things that don't each need the disruption of a full blown meeting
• Consider whether the subject matter itself actually needs to be discussed in the first place. Half the meetings that take place in the office are about things that are so unimportant that they don't warrant further discussion let alone a whole meeting!

Meetings are great for making you look busy, and great for giving you something to do when you're bored but there are better solutions to cover both those situations. If you can cut down on the number of useless meetings you set up and have to attend, it might even make the useful meetings work even better!

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!

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.

Unused Information Holds Many Answers

Twitter can be a wonderful source of inspiration for a blog entry especially for an old pro like myself, who has encountered so many "coachable moments" that sometimes I forget what I want to share. So, thanks to the Standish Group for the inspiration for this entry with the following Tweet:

"44% of CIOs say it takes on average a day or less for their organization to reach a standard IT project decision"

This caught my eye and I responded by rhetorically asking how they measured that - probably a finger in the air. A few days later Standish came back to me with the response that "it was asked in our monthly DARTS survey of over 300 CIOs [which] had many questions on decision latency, complexity, & costs". It wasn't my intention to question how the Standish Group came about their data - rather how CIOs could actually provide a measured response in the first place?

In 28 years of working in the IT industry I have never seen a project, programme or business area maintain quantitative time related data on their decision making processes (except in my own projects!). If that sort of data is not available at the lowest levels of the organisation, I'm struggling to understand how a CIO can honestly answer the question on behalf of the whole business.

Standish have since tweeted lots more amazing stats based on their survey such as "39% of CIOs say it cost on average $500 or less for their organization to reach a standard IT project decision".

But how CIOs or anyone else responds to these questions isn't really the main point of this post. I'm interested in why teams (read departments/groups/functional areas as well as projects/programmes) don't record such data, and if they do, why they don't use it to better understand the way they operate.

Most projects maintain some kind of RAID log - probably using a standard template which came from the CMMI programme or PMO - and go through the regular motions of entering data and reviewing the outstanding items so they can close them. They probably prioritse each item, and assign a degree of severity. They may even put in open and close dates, but they rarely, if ever, do any analysis on the data, other than to monitor the number of open and closed actions over time (which generally tells you very little at all).

As a process management person I view these logs as an valuable source of input, if you're prepared to put in some effort and ask some awkward questions. Why do some issues take weeks or even months to close? Why should it take 10 days to reach a decision? Why don't open issues get reprioritised after a certain amount of time. Are there connections between the types of issue or decisions that cause the most problems?

These are the types of question that should be getting asked at departmental reviews, stakeholder reviews, and quality reviews but generally get ignored in favour of the familiar questions about timescales and budgets. If you ask different questions at these reviews, establish root causes and fix the problems, issues around budgets and timescales will probably start to fade into the background.

I find it bizarre that organisations spend so much time tracking code defects (rather than getting on with the business of fixing them as they arise) but seem to ignore management defects until they have actually caused operational failures.

While managemement continues to highlight time and money as the only critical yardsticks by which performance is measured, quality will always be an afterthought and the entire organisation will suffer as a result.

New starters: What a Waste...?

It never ceases to amaze me how poor organisations are at taking on new staff. I don't mean the recruitment process per se (don't get me started on that one), but the set of physical activities that need to take place in order to get a new employee (whether full or part time, permanent or contractor) up and running and being able to contribute to the organisation in as profitable manner as possible. I'm sure everyone has experienced the frustration of getting to work on the first morning of a new job, and finding a set of obstacles in your path.

Examples include :-

• finding that the people supposed to meet and greet you aren't available
• there's nowhere for you sit
• no computer is available
• security passes and building access are not set-up
• network access is not configured
• you weren't expected for another week…

Even if most of these elements are in place, very often the first few weeks are spent sitting around reading piles of mind numbing documents, meeting huge numbers of complete strangers who you'll probably never deal with again (and whose names you instantly forget), figuring out how to get an outside line on your phone, having lunch on your own, and generally waiting for something to happen so that you can start to feel useful.

In my experience IT companies or departments are usually the worst places to start working in, generally for most of the technical issues listed above. It also seems to the case that the bigger the organisation, the longer it takes. Here, the problem is often exasperated by the fact that the HR, facilities management and corporate purchasing departments have been outsourced, increasing both the timelines, number of  communication lines and the number of issues needing resolution.

Given that the recruitment process often takes several weeks - if not months, even for critical hires, there is really very little excuse for not having everything ready for the new starter on day one, or at worst day two. Sometimes signatures are required on contractual, legal and security documents and photographs need to be taken for ID cards, but at least time could be allocated on day one for these activities to take place.

If an employee is to be productive he or she generally needs somewhere to work and some tools to work with. Computers can be pre-ordered if not already available. These machines can be pre-configured according to the new starter's role. Network access can be pre-arranged and appropriate shares to project data repositories and corporate tools allocated in advance of the start date.

But for some reason, organisations seem to be quite content to have their new, sometimes very costly, resources hanging around twiddling their thumbs, pretending to look busy, and trying not to feel guilty for something completely out of their control. In these days of cost cutting and the insurgence of "lean management" it is a complete mystery to me why organisations are quite happy to waste tens of thousands of pounds, dollars or Euros by having keen and eager employees loitering with intent to become productive.

.



Where waste is rife but apparently acceptable

This blog entry may not sit easy with some readers but will have others nodding their heads in sad agreement. In the current recessional climate, many large organisations are bending over backwards to divest themselves of their staff. Loyal, hardworking and smart people are being laid off in their scores and face an uncertain and uncomfortable future. At the same time, those left behind appear to demonstrate that poor management and general incompetence is normal and acceptable behaviour, and continue to be rewarded for it. It seems that the Peter Principle is now a key criteria for promotion. Organisations that have become accustomed to working with bulging levels of untrained and unqualified middle management are now burdened with an unprecedented amount of waste which they appear to be unable to prevent. In most cases, the inability to deal with this waste is because it goes unrecognised and unnoticed, except in the worst cases where it is actually ignored. Some of the problems are due to the fact that many managers now act purely as conduits. Their sole function in life is to delegate everything down the chain until it reaches the lowest level at which point everything flows back up the chain to the original source. Additional requests for information or action then repeat the journey until the next set of demands appears. At no stage in the process is value added. In fact the reverse is more likely to be true as “Chinese Whispers” take effect. Good managers lead by example. They get their hands dirty, not to the point of micro-management, but they recognise that there are some tasks they can or should undertake themselves without having to disrupt their staff. Constant delegation without thought actually puts staff into difficult positions. I’ve heard of organisations delegating activities associated with pay-cuts and layoffs to junior members of staff who do not have the appropriate levels of authority or access to deal with such information. In other situations, procurement departments are circumvented at management request to expedite purchasing activities. Again, it is often non-managerial staff who are put in the firing line for failing to adhere to policy and process. Management by pure delegation is often associated with management by email. Staff are given insufficient detail, information and time to deal with orders handed down by vague and curt emails. The premise is that if you are at the bottom of the chain you can clearly stop everything to deal with the most recent urgent demand. In big organisations, it’s all too easy for poor managers to hide behind each other. This is unacceptable waste, and managers found to be lacking should be reminded that they have to add value to the organisation just like everyone else. A failure to deal with this will ultimately cause catastrophic failure in the organisation, as managers who don’t “do“ suddenly find that there is no-one left to ”do“ for them. And the people who know how to ”do“, have long since left the building.