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!


.

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

.

When Measurement Programmes go Viral...

I think it’s a fair comment to say that only a foolish manager or leader would try and run an organisation, department or even a project based on subjective judgment alone. Gut feelings and intuition should not be ignored but they need to be backed up and supported by facts and often the best facts are quantitative. I have come across plenty of managers who follow the ostrich tendency and genuinely believe that they understand how their organisations perform but reject any type of data collection. Luckily they are in a minority and they aren’t the focus of this post.

If ever you attend a course, seminar or conference presentation on the implementation of a metrics programme in an organisation there are usually several repeating themes:

1. Metrics collection is only worthwhile if you use the numbers to take actions
2. The cost of data collection must not outweigh the value of the data
3. Data quality is paramount – poor quality data is usually worse than useless
4. Start off by collecting the most useful data, based against your objectives, and build your programme on that basis
5. Continuously review the data you collect and get rid of those measures which no longer add value
6. Don’t use the numbers to beat up your people

The Measurement and Analysis process area of CMMI is one of the easiest PAs in the model to understand. In the main, it is written in jargon free English and it follows both a logical and a chronological path. In short, it ain’t rocket science.

Yet in almost every organisation I’ve worked in it brings fear to the heart of the process teams, fills project managers with dread and often has so-called metrics subject matter experts rubbing their hands with glee at the thought of the power they will be able to wield. In some organisations some managers will also delight in the prospect of new ways to command and control their workforce whilst others will react with complete apathy (“we’ve seen it all before and it won’t work”), and still others will share the same fear as their staff.

So why do so many organisations get it so badly wrong?

There are a few places that get a good balance with their measurement programmes, but too many fall into one extreme or the other. Some organisations simply pay lip service to the requirements and do just enough to think they’ll get through an appraisal. But in this piece I want to look at the organisations that go to the opposite extreme and overwhelm the organisation with useless, redundant and time consuming measurement activities – again with the simple objective of meeting the needs of an appraisal rather than focusing on the real needs of the business. These are the organisations where measurement programmes have gone viral.

Imagine the scenario; an organisation has set a goal of achieving CMMI Level 3 within 24 months (I know – it’s a bad goal, but we all know it happens). The SEPG and steering committee agree that they need to ramp up the measurement programme because they don’t have enough going on to achieve Level 3 based on arbitrary perception rather than a genuine business need. Someone is appointed to head up the programme who is a naïve but ambitious PMO manager as opposed to a management or business expert (or even a software engineer).

Within weeks, a deluge of new measures are mandated and the already overextended  project managers now have the burden of collecting and submitting each and every new measure through a system of manual data entry sheets within yet more arbitrary timescales. No explanations are available as to how the data is to be used or how it will benefit the organisation. Of course, none are necessary because collecting data is a “good thing” and a CMMI requirement, and therefore it must follow that more is better. A team is put together to generate a set of internal dashboards which are built using complex excel spreadsheet and macros and a compliance team is set up to monitor the whole activity to ensure that there are no missing values. The spreadsheets are published to senior managers and a series of compulsory review meetings is established. Each and every aspect of each and every project is examined and corrective actions are created to bring deviants back in line. CMMI requirements are therefore addressed and the outcome of the forthcoming appraisal is in the bag. Everyone is happy (except the PMs, but they don’t count).

With this success story behind them, there is only one place to go for the measurement programme – the accumulation of more data, the development of bigger and better dashboards, and the total domination of the PMO across the enterprise. Yup – we’ve gone viral.

Of course the reality is that behind the scenes, the project teams are making up the numbers to comply with the data collection process – putting something in is better than getting in trouble for failing to submit anything at all. Managers largely ignore the data, because they are overwhelmed by it, and don’t really understand what all the numbers mean anyway. Dashboard reviews become repeats of the other management review meetings, and no real or useful analysis can be performed at any organisational level because the data is just one humongous and homogenous blob.

In many cases the organisation will achieve its goal of reaching Level 3 because they’ve done “enough” to get away with it, but everyone knows that it’s a bit of a sham. Emphasis on measurement falls away over the next six months (along with all the other non-institutionalised processes), and the pre-appraisal status quo is restored, until the next appraisal in three years time when the frenzy will start all over again.

So what can you do to inoculate yourself against this behaviour?

1. Look at the M&A Process Area in detail – nowhere does it tell you that a certain number of measures should be in place to be operating at any specific CMMI Level
2. Align a few key measures against your specific business objectives, and focus on getting good quality data. Involve business leaders in the selection of the measures so that they can get nearer to the solutions to the problems that cause them pain
3. Look for measures that will help projects and project teams not hinder them, and don’t overburden projects with demands for duplicate data or data that can be found elsewhere
4. Provide explanations of how to interpret the data. If you can’t do this, you have no right to demand the data in the first place. You also need to remember that different groups of people will have different objectives so do not take a one size fits all approach
5. Perform appropriate analysis and publish findings along with recommendations of collective actions that can/should or must be taken
6. Review your measures on a regular basis and throw out redundant ones or ones that don’t add value to the organisation. Review the cost of data collection at the same time.
7. Get reactions from the “shop floor”. If your metrics programme is causing your people pain, it’s probably doing something wrong and it needs fixing
8. Align the expectations of managers and information providers – in others words perform some serious stakeholder analysis and relationship management
9. Instead of worrying blindly about compliance in providing data, concern yourself with why the data may not be being provided, and instead of analysing missing data, examine outliers and significant deviations from expected values
10. Stop treating CMMI as an objective and focus on doing the right thing for the business, with CMMI as a (one of many if possible) reference model to guide you

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.

.