Thursday 3 February 2011

The Madness of Starting Point Schedules

Even the most passionate supporter of the CMM and CMMI families of process improvement frameworks can't help but admit that they have caused organisations and individuals to do some pretty stupid things in the desire to achieve a Maturity Level. I also find it interesting how things I once thought of as super cool, now really annoy me, partly because I never really thought through the implications myself, and partly because as I've become more experienced I understand better about how and why these things should never have seen the light of day. One of these things that has been in my mind a lot recently is the project management starting point schedule.

Let's just clarify what I mean by a "starting point schedule". I use the term to refer to an MS-Project template which has a set of predefined entries on a Gannt Chart. It will usually have standardised headers and footers which conform to the organisational standard, and may have some standardised calendars and rates set up in the resources sections.

Why is there a need for such a template? In my experience, quite often, the most significant part of an organisation's initial approach to process improvement is a frenzied effort to create a library of standardised document templates. It's as if they simply think in terms of CMMI as being document oriented (not unreasonable for a novice SEPG who have "achieve CMMI Level 2 by the end of next year" as a goal, and who have learnt that a SCAMPI A appraisal will require the production of thousands of project documents as evidence). If you are going to create templates for all your other project management documents, it kind of makes sense to create a template for a project schedule also. Regardless of the rights and wrongs of this approach, I'm just going to focus on my starting point schedule in this post.

So having acknowledged that you are going to create a starting point schedule template for the sake of completeness, the next discussion is usually around the matter of what activities you put in it. And this is often where the first signs of madness manifest themselves. Because it's usually the SEPG who create these templates, they focus on all the process activities, and the initial schedule consists of all the process steps in the quality management system associated with projects. And to make matters worse, the schedule is actually organised by process area. It's as if they are saying to the appraisal team: "look, all the process activities are in the project schedule, therefore it's obvious that they are planned and managed".

The end result of this activity is that our starting point schedule consists of between 100 and 200 activities, not one of which is actually of any value to a project manager who is only interested in delivering product rather than performing process.

But the next bit of madness manifests itself when the Enterprise PMO gets hold of the template. They have to put their imprint on it, and now a set of arbitrary milestones are embedded into the starting point schedule. These enable the PMO to keep an enterprise level view of all projects and programmes so they can see when milestones are missed and can enforce corrective action (!)

Next the accountants and invoicing team get their hands on the template and insist on their work breakdown structures being embedded so that the project activities and the project accounting and billing systems align without anyone in the billing department having to do any work.

By now you have a starting point schedule (which senior management have mandated to be used on all projects) with 500 entries on a Gannt Chart of which not one is actually related to doing any real work in respect to a project delivering a product or outcome.

The starting point schedule is no longer a tool that the project manager can use to track the progress of their project. It has become a noose by which to hang the PM when non-project specific activities are missed out or delayed.

And people wonder why PMs go off and use their own schedules and tools to actually manage what they are paid to do.

The project schedule is a PM tool - it's not an accountancy, billing or invoicing tool. It isn't a workforce management tool, and it most certainly is not a process compliance tool. I agree there are some overlaps, but use the right tools for the right job, especially if you want the job done right.

And a reminder to SEPGs who create the templates - if you want to do it right, you should create the work breakdown structure template first. Let's see you trying to put 200 process activities on a work breakdown structure using MS Organisation Chart! Now, if you must create your starting point, keep it simple! An over complex starting point schedule will actually lull a PM into a false sense of security because they fail to focus on project specifics amongst all the detritus now living in the schedule.

One final argument I often hear for the all encompassing starting point schedule is that it helps non project managers who are running projects understand what they need to do. Actually, I think you'll find that reading a book on project management might be slightly more effective, or maybe a training course? Or, perish the thought - get project managers to run your projects!


.

Wednesday 2 February 2011

A Trip Back to the "Bottom of the Ladder"

I've worked as a "management" consultant, either internally or externally, for the best part of 20 years now, and I've often heard people say that all consultants should occasionally step down from their ivory towers, and go back to their roots. It's not very often that I've heard of any consultants taking their own advice, unless it's a career move, but recently I did just that, although not through choice or design. I've spent the last six months working back at the coal face as a project quality manager. Now I can let you into a secret: it was not a fun experience! It was interesting, challenging, frustrating, and at times just damn hard work, but fun is not an adjective that readily springs to mind when talking about the engagement.

So why on earth would I want to write about it? That's easy; I now fully understand why every consultant should do the same thing and that's what I really want to share with you.

Before I go any further however I want to make an important statement. The organisation I was working for showed me nothing but respect and I would gladly work for them again in a different role. The people I worked with on a day to day basis were professional, open to new ideas and accommodated my slightly maverick and off-the-wall approach and this included both managers and project staff. The organisation itself is a very large, world renowned, and highly respected financial institution, and it won’t do me any harm whatsoever in having it listed on my CV. It has its headquarters in continental Europe where English is not the first language (but where it is the accepted business language), and as a financial institution it is part of a highly regulated and somewhat conservative industry, especially when it comes to quality. Of course, as a large organization with a distinct culture built up over many years, change can be difficult to manage, and therein lies the heart of my discontent during my tenure there.

I’m used to leading change in organisations, either directly as a programme manager or in an advisory and consultancy capacity. I like working with the “big picture”, although I’m happy to work amongst the weeds to better understand what’s really going on and I have no problem understanding and working with the little details. In the project quality management role, I experienced first hand the deficiencies of an industrial level process improvement programme and set of quality policies which I have fought so hard to change in the past. As an external contractor, on the lowest rung of the quality ladder, my day to day existence was spent adhering to internally imposed quality standards and practices which, for the most part added little or no value and which I was unable to push back against. More frustratingly, my views were clearly shared by many of those around me including my managers who were also manacled by these policies created by an apparently intransigent central process and quality team which was deaf to genuinely useful feedback and refuted that they have any obligation to change their own behaviours. It is one of the worst cases of ivory tower syndrome I have ever encountered, made even worse by dint of their being geographically removed from the hub of the delivery operation.

The quality culture, as applied to process improvement, was partially diluted and confused by the decision to outsource a large tranche of the process improvement activity to an external consultancy from India. Although senior managers were home grown, the volume of external consultants overwhelmed the internal staff, and they effectively imposed their own process improvement culture on the organisation. Now I'm all in favour of bringing in external consultants to assist in developing process management capability; otherwise I'd be permanently unemployed. However, I don't agree in outsourcing, en masse, something which has to be developed organically.

During my incumbency the organisation underwent the scrutiny of a CMMI Level 3 SCAMPI A appraisal and two of the projects I was working on were in scope as non-focus projects. This gave me an even better understanding of how and why some things were as they were, but still did not excuse the basic errors that were being made in terms of overall process and quality management. It was as if this was the first process improvement programme in history, and there was no history to learn from. However, I won't dwell on that just now.

Regular readers of these posts will be able to recognise how frustrated I was by the end of six months, and why I just wanted to get out and come home. But it was important to come home with something other than negative thoughts, so I spent some time reflecting about my own behaviour in the past, and what lessons I could learn to apply to future engagements. This is my list, and it is specific to quality and process management consultants

You are a Change Agent First

You are first and foremost an agent of change and if you don't understand the basics of change management, stakeholder management and relationship management go and find another job. Changing they way people do things needs their cooperation and collaboration. You need to listen to them and engage in dialog with them.

Command and Control Doesn't Work

Old fashioned command and control management doesn't work for quality and process management. People need to understand why they are expected to do certain things (which may appear to be completely worthless) and if your only explanation is "because we tell you to" they will find ways around it and everyone could suffer as a result. If you only make recommendations that add value it will help, but you still need to win hearts and minds.

Be Prepared to Admit You Are Wrong

I've often used the phrase "I'm not always right, but I'm never wrong", but only in jest (I hope). Sometimes you will come up against people who may be wiser or smarter than you, and you need to acknowledge that and let them correct you. Don't just sit there and rely on your authority; listen to what is being said and make the appropriate changes and acknowledgements.

Look Out for Learning Opportunities

Only the very arrogant think they can get by without improving themselves and learning from others. Sadly, I've met a lot of very arrogant consultants and managers. Sadly, too many younger consultants have no actual work experience other than as consultants and they are unable to accept that those who have done things (or are still doing them) have any value or anything to offer.

Don't Impose Your Standards on Others

Just because you have a tried and tested way of doing things doesn't mean it's always going to work. And that is true with individuals, teams and organisations. You cannot and must not try to impose your culture and values on others. Instead, work with them, and let them choose what is appropriate for them.

If It Isn't Working, It's Probably Wrong

When you've put a plan or a system or a mechanism or a programme in place and you aren't seeing the desired or expected results one of two things may have happened. You didn't know what to expect so you can't recognise it when it happens, or more likely, you've done something wrong and it needs changing. This is a bit of an extension to my third point but on a larger scale. It's no good persisting with something in the hope that it will improve. Learn from what's happened, change what needs to be changed, and move on. If necessary consider whether it is time for you personally to move on permanently...


I hope these six values are already engrained in my own ethos as a consultant and as a person. I'm sure I've been guilty of not following all of them in the past, and this experience has made me acutely aware of potential pitfalls in my chosen area of expertise. All experiences are learning opportunities, and this was a timely reminder of what to think about next time I set foot in someone else's organisation and before I start to tell them what they need to do!

As for you, dear reader...take a six month break from consulting, and go back and do some proper work for a change. You might just find it changes your outlook on life! And besides, why should I be the only one to suffer?!

.