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!


.

Criteria for Creating Project Artefacts

If I take a look at the people I follow on Twitter (currently about 1100) they fall into roughly several main categories listed here but not in any specific order:-

• Process and Quality Experts (including CMMI, ITIL and ISO specialists)
• Apple technical experts (including magazines and developers)
• Apple fanboys and girls
• Business leaders (non-IT)
• Musicians and other "celebrities"
• Journalists
• IT professionals

Out of all the IT professionals, nearly all of them are self proclaimed Agile practitioners, managers or gurus. Why do I mention this? Well mainly because I don't believe that this reflects the real state of the larger world where I suspect the Agile sector is much smaller than the more traditional development approaches. Even within the Agile sector, I suspect there are only a tiny percentage of people "doing Agile properly". Of those who do, most of them seem to spend most of their time on Twitter, so I'm not sure how much they really practice what they preach!

By and large businesses still run fairly old fashioned IT programmes and projects, and very often these projects follow quality management systems that are somewhat over-engineered and overblown. Personally, I think I fit somewhere between the two places - I don't count myself as an Agile practitioner although I was part of the DSDM movement many years ago, and I have an aversion to heavy weight development and management processes and methods.

Even with heavy weight process sets, most standards encourage tailoring of the process and the project documentation so that it aligns with the specific requirements of the project. In other words, you do what is necessary and ignore what is irrelevant. Quality and process 'experts' are on hand to assist the project or programme manager make these 'difficult' decisions, and to help the project team members create the project artefacts that are deemed to be required.

Which brings me on to the real gist of this post, namely that there is something wrong with this approach. If a project manager doesn't know what a specific project artefact or process is all about or cannot make a decision about whether or not a particular artefact should be created or process followed then there should be some serious questions about whether he or she should be managing a project in the first place.

This isn't aimed solely at project managers, but anyone involved in the planning and execution of a project, including developers, testers and business analysts.

For me, there are really only three criteria which should be used to judge whether a project artefact should be created or not.

• Does it add value?
• Will the project be at risk if it is not created?
• Do you know why you are creating it? (because I've been told to is not a valid answer)

If the answer to the last question is no, then the next question should be "Am I the right person to be doing this job?"


 .

Watch out for Waivers

Tailoring the software process is a fundamental aspect of software process management but is often poorly understood by inexperienced process teams and badly executed. This generates confusion amongst project managers and project team members and often leads to an undesirable behavioural response whereby tailoring is ignored in projects and process anarchy gains a foothold in the organisation. One key failure is to confusion between the tailoring process and the waiver process. Process tailoring (as defined by the SEI) is :

"The activity of creating a process description by elaborating, adapting, and/or completing the details of process elements or other incomplete specifications of a process. Specific business needs for a project will usually be addressed during process tailoring."

Typically a process element is an input, output, role, activity or procedure, but not restricted to these. Crucially, the act of tailoring does not change the underlying purpose of the process or process element. An example of process tailoring is to select which of the standard project management deliverables a specific project will create. Similarly, small projects may tailor the standard lifecycle to follow a less rigourous start-up process than a large project. Process tailoring decisions are made during the project launch, should be based on tailoring guidelines and are agreed with the relevant stakeholders according to specific business needs.

A Process Waiver on the other hand is a mechanism that allows the applicant (for example a project or business area) to refrain from applying or following a process. Very often process waivers are a mechanism to allow a project to perform non-conformant processes or activities.

An example where a process waiver might be used is when project is contractually required to use the client process set rather than in-house processes. Process Waivers are usually granted on a temporary basis according to an agreed business case, and are reviewed on a regular basis to ensure their currency and validity.

Neither process tailoring nor process waivers should be performed as 'get out of jail free cards' undertaken because an individual or team has elected that they don't wish to perform certain activities.

Process tailoring should be performed by all projects as part of their launch. Process Waivers should be exceptional. If projects are generating large numbers of waivers there are likely to be three possible underlying causes. Firstly the distinction between tailoring and waivers is not understood. Secondly, the tailoring process and guidelines are inappropriate, or in the third and worst case, the process set itself not properly aligned to the work being undertaken. The process group (or equivalent) should be maintaining records of all waivers and performing trend analysis against the data to establish potential process improvement opportunities. Records of tailoring decisions should also be kept for the same purpose.

One final thought is to pay attention to the granularity of process tailoring guidelines. At a minimum, process areas and process inputs and outputs should be included. Some organisations attempt to tailor at a lower level, such as tailoring of sub-sections within documents. Unless there is a very good reason for such a level of control this is probably a step too far and will generate mistrust and resistance from those people who have to create and use the documents. A good review process and culture should trap potentially critical documentation errors whilst still allowing the authors the ability to make some decisions for themselves, and will also allow a best practice culture to grow and thrive.

There's enough of a nanny state out there without needlessly bringing it into every aspect of working life as well.