How do I know it is a “good one”?

Make your information count

Programme and project management relies on information, much of which is contained in documents and tools. Good practice (and indeed common sense!) says that a deliverable needs to be verified to ensure it is fit for purpose. So, for example, software deliveries are verified through formal testing. Documents are “reviewed” by the appropriate people before they are approved. But who are the “appropriate people” and what are they looking for when they review a document? How do they know it’s a “good one”?
Good documents as a basis for rigorous decision making and baseline management
Most programme and project management information is contained in documents. All the key ones are defined in templates, which act as a prompt to the author to ensure the right information is included. Templates also ensure there is consistency in terminology and approach, so that the people who review the document (and later approve it) don’t waste time resetting their brains to yet another “way of doing things”. The documents form the basis for decision making and for setting baselines. Good documents lead to more rigorous decisions and control.
The product description as a key enabler to “good”
Coupled with every significant template you should have a “Product Description“. This is a technique taken directly from PRINCE2 which helps ensure the documents which are produced are fit for purpose. The product descriptions contain key information defining:

• composition what the deliverable is made up of
• quality criteria which can be used to judge if the deliverable meets the need
• review skills, suggesting what skills reviewers need to have if they are to be effective
• tailoring guidelines, which say how you can change the template to suit your particular needs.

By including standard product descriptions in your enterprise approach, you can save your company time as your people do not need to develop their own each time.

What on earth is a “Workstream”?

A lot of my colleagues thought this would be a good topic for a blog. Do you know what a “workstream” is? Does everyone have the same interpretation of that word? Are you sure? I assume someone, somewhere does, as it is used very widely in many companies (probably driven by some consulting organization!).
Some quick research
I did some quick research and found that this word does not exist in any formal project management methodology (for example PMI, APM, DIN, PRINCE2).
The often quoted Max Wideman glossary makes no mention of it.
A quick scan of the web comes up with comments like this, which was in response to a person asking what the Spanish for “workstream” is:
My guess as to why you are having difficulty pinning down the meaning of the term “workstream” is this extract from a response to a forum question:

I think it is a proper name of various businesses and software packages which is gradually leaking into professional jargon for more general use. I think “workstream” has not yet reached the status of a real word with a settled meaning. I won’t go so far as to suggest that it is meaningless, pretentious jargonspeak. But . . . .

It can’t be translated! This rather explains why, on my work on the new international standard on project management, I haven’t come across it. The International Standards Organisation (ISO) only uses plain English terms from the Concise Oxford English dictionary, which are translatable. The Project Workout is aimed at international readers and so I have taken the view that everything in it should also be translatable.

Even Microsoft Corporation, that great source of jargon and acronyms, doesn’t include the word in its spell checkers.

Looking at real organisations, I have identified “workstream” to be used synonymously with a “department, function or directorate” and a “sub-programme”, which are entirely different dimensions in the classic organisation matrix. I also found it was used to group together virtually any number of unclassifiable clusters of activities.
The Project Workout
The Project Workout does not contain the term “workstream” for all the reasons given above and yet it is in common use, We are not living in George Orwell’s “1984”, so you can use the term “workstream” if you really want to, but if you do use it, consider exactly what you mean and what management procedure would be used to manage it; if you can’t determine that, then you can’t expect anyone else in your team to understand you.

My advice – don’t use it!
I am sure people will still use the term, perhaps because it is such excellent fudge or perhaps it just sounds “cool”, “techno” or even “heroic”! My advice is to avoid using the word, when we have well defined, plain English, alternatives. What do you think?

When a plan is not a plan at all!

The word plan is used frequently in day to day conversations and most people have a good idea of what a “plan” is. However in a programme and project management context things may not be quite so clear. One common mistake people often make is to believe the “plan” is just the timescale, as shown in a Gantt Chart. However, whilst the timescale (or schedule plan, to give it its formal name) is vital, it is only one part of the overall plan. The other aspects include:

• costs,
• resources,
• accountability,
• WBS
• and, often, benefits.

These are often bundled together into a narrative document such as a Programme Plan or Project Plan.

This holistic view of the term “plan” is what is used in PRINCE2, BS6079, PMI and APM publications . . . and that is also how we use the term in the Project Workout. You can find out more about planning in the Project Workout, Part 4.

Good programme and project plans can take many forms and any enterprise approach should allow a programme or project manager a wide degree of freedom in how to document this. Standard Product Descriptions, which contain tailoring guidelines are good place to document such guidelines.

So, next time you are asked for a “plan”, check what the person is really looking for and don’t jump to conclusions that what you define as a “plan” is the same as theirs.

What is a project? (groan)

When I hear this question at a seminar or conference, my heart usually sinks. Here we go with a lot of pedantic waffle. “ start, end, unique” etc. In a general sense (and seminars and conferences are nearly always “general”), the precise definition of a project doesn’t really matter. Most people attending such events have enough of an understanding otherwise they probably wouldn’t have signed up. However, start moving into the context of enterprise-wide project management and the use of a term such as “project” can make a lot of difference.

Buttrick’s first law of naming: Anything called “xyz project” might actually be a project. Anything called “Project abc” probably isn’t!  It is just that some people think its sounds cool and modern to write backwards.

But my project isn’t like that?
If your idea of a project is different from mine then we could get into a bit of a muddle if we tried to work together. At one end of the scale we have the “school project”. Is full scale “project management” the right procedure for your kids to use to manage that? Absolutely not! Closer to the work place, I expect you’ll find that there is a lot of work undertaken which people call “projects”, but which in reality are bits of projects.

What! You want me to write a Proposal and a Business Case/Project Definition, get a sponsor, set up control logs, provide progress reports, do a bit of stakeholder management etc etc ,when all I am doing is installing a new server. I always knew this project stuff was an administrative nightmare!

Often these are simple “initiatives”; for these, the use of full scale project management would be a huge, non-value added overhead. (This is often where Agile techniques are used or in many cases where routine operational processes are needed). If full scale project management seems like overkill for your “project”, then consider whether the work you are doing is a project at all. It might be a work package and so a simpler approach, using key project management techniques, such as planning, may be more appropriate.

Understanding the difference
The glossary in the Project Workout defines the terms. Both projects and work packages have a start and end etc. but there are TWO important differences:

• Projects are aimed at a achieving a stated business objective, as opposed to contributing to a lot of other stuff, which when put together enables an objective to be achieved.
• Projects have to have a staged lifecycle, which is used to manage risks. Project work is risky enough to warrant a senior management decision prior to starting each stage. The riskier the work, the more stages there are. I have seen 12 stage lifecycles for projects relating to key aircraft components, which if they failed would cause the aircraft to crash. Work packages can be approved as a single lump. Project lifecycles are not development processes, where the stages are based on technical content. See the Chapter 3 of the Project Workout for more on this.

So, when you find yourself thinking that that “project management” is too heavy, it may be that your work is better described as a work package, which has a simpler management approach.

Think about this

1. Just because a person who is called a “project manager or director” is doing the work, it doesn’t make that work a “project”.
2. Cost is a very poor indicator of the size or complexity of the work. One person’s work package may dwarf another person’s project in cost terms.
3. The “real work” happens in “work packages” managed by team managers who are skilled and competent in the work outputs being developed, not necessarily project management.
4. Team managers (all managers!) require a minimum level of project management skills, even though they may NOT be “project professionals”.

Where to find more in the Project Workout

Chapter 3 is where you will find out more about projects and the importance of project lifecycles.

Don’t waste your time planning!

Do you sometimes (or often!) hear the words, “Don’t waste your time planning, just get on with it!“? Do you agree? If not, do you know how to respond? This blog looks at one fundamental aspect of planning, the schedule plan, and explains why planning is vital.

What a well produced plan tells you
You will find the management of the schedule is one of the most important and fundamental of project management techniques. So much so that many people (wrongly) think that schedule management is project management. At a simple level, the schedule tells you how long the programme and project, or any part of it, will take. In addition to giving dates, a well produced schedule plan also tells you:

• who is accountable for every aspect of the programme or project;
• escalation routes;
• reporting channels;
• the approach being undertaken;
• the major deliverables from the programme or project;
• interdependencies (gives and gets);
• the timing of key review points and major decisions;
• payments;
• constraints (such as “freeze periods);
• benefits recognition points.

The schedule is also the basis on which cost and resource plans are constructed. However, unlike costs and resources, which are seen by only a few people, key dates are very visible. A well publicized delivery date is, when missed, very hard to hide. While “time” may not be the most important aspect on some projects, an observer may develop their own perception of “success” or “failure” purely from the performance against the publicized target dates. The ability to build and manage the schedule plan is one of the essential skills that all programme, project and team managers should have. Planning is far too important to delegate to junior team members, especially in the early stages when the overall strategy and approach are being developed. The plan sets the course for the remainder of the work.

The benefits of good planning
Done effectively, the schedule plan will benefit your sponsor, you and the team by providing:

• a   baseline against which to measure progress (without a plan, words such as “early” or “late” have no meaning);
• a common understanding of the approach being taken to achieve your sponsor’s objectives;
• a breakdown of the project workload into manageable pieces (work packages) based on the deliverables/outputs wherever possible;
• a clear way of showing interdependencies between activities and work packages within the project and to/from other external projects;
• a listing of accountabilities for different work packages and activities;
• a tool for evaluating when corrective action is needed.

Further, the actual activity of creating a plan by using the full team serves to forge a team spirit and a high level of common understanding and commitment.
Know your risks
All programmes and projects are undertaken within an environment of risk. Good planning is done in the full knowledge of those risks. You should therefore:

• avoid avoidable risks by planning the project in a different way;
• contingency plan for the unavoidable risks.

All organisations need to make provisions for risks in their financial accounts; without planning how can you know what these are?

Enough planning is enough
A good plan is not necessarily a detailed plan with lots of activities. Micro-planning can be damaging as it is time wasted. The granularity of the plan needs to reflect the risk associated with the work, the phase or stage of the work and the need for effective monitoring and control. A key tenet of planning is plan the immediate work in detail and the rest of the work in outline. This applies whether using “classic” or “agile” approaches.

Plans can change!
Once a plan is produced and agreed it should be baselined and used to gauge progress. However, that is not the end of the story. Things may change either within the project or outside it, which will cause us to re-plan and re-baseline. Never consider a plan to be fixed, but only introduce changes when you really know what the impact is.

Finding help in the Project Workout
Chapter 21 of The Project Workout covers schedule planning and the accompanying CD includes is a Microsoft Project template, which includes all the key “best practice” features described in the book.
Chapter 25 deals with change control.