No white space = unhealthy company

In an earlier blog I talked about the three necessary conditions if you are to manage your resources effectively (see Link). Resource management is a hot topic in many companies and is the primary driver for them implementing programme and project management systems.

In this blog, I’ll talk about what I refer to as “white space” and why, if you haven’t got this, your company or organisation is in an unhealthy state.  So what is “white space”? The gap between what your resources are committed to and the total resource you have available is ‘white space.’ It is the resources that you have not yet committed to a given activity or project. If you fulfil conditions 2 and 3 from my earlier blog, you will know your white space:

White space = resources available – resources already committed

In the very short term this should be small. It will grow as you look further into the future.
White space is fundamental to a organisation’s on-going health. If you haven’t any in the short to medium term, you are paralysed. You have no one available to change the business to meet new threats or exploit new opportunities unless you withdraw them from previously committed work. White space gives you the resources to effect change in the future.
‘We are in a fast moving environment’ is the common mantra nowadays. If this is truly the case, then you need to ensure that you have ‘white space’ resources ready to meet future needs. You know the people will be required but you are not yet sure exactly what for. If you have no people to change things, things won’t change.

White space must cater for two distinct needs:

● First, it must cover the need to undertake initial investigations from new proposals. People must be available at very short notice to do these and must be highly knowledgeable if the investigations are to have any value.
● Second, you need the resources to undertake the future projects or work.

Compare the former to a company putting a bid together – if this is done by inappropriate people, the timing of when bid and what bids are needed is unpredictable, the bid may be lost or the company may have committed itself to a financial disaster. Just because business projects are  ‘internal’ it does not mean you need not apply the same rigour as you would with external matters. It’s your organisation’s future at stake in both cases.

The figure represents ‘white space’ in graph form. It could apply to a complete organisation, a division, a function or whatever. However, unless you can build this picture you will be taking risks every time you need to set off another initiative.

One of the challenges I have found is that many organisations plan on an annual basis and the financial controllers insist that every work item for the year is itemised and budgeted for, believing that this will ensure efficiency; they simply won’t allow “white space” and expect managers to have 20:20 forecasting vision . . . even in a fast moving environment.  White space is what enables an organisation to be nimble, fast moving or agile (choose your own buzz word).

You can find out more about resourcing in Chapter 14 of the Programme and Portfolio Workout.
 

I thought you were doing that!

If you haven’t got accountability right, you could look pretty stupid.

Whenever I am called into a conversation on who’s accountable for this or responsible for that, things soon get out of hand as everyone starts to argue what “RACI” means and forgets about why they are there. By the way, it should be “ARCI”, but that doesn’t sound very nice.

Putting that aside, let’s look at this from a different angle, which looks at mind-set and behaviour. I came across this approach from a New Jersey company called London Peret Roche.

Accountable: what a person is accountable for; it includes WHO they are accountable to. If they aren’t accountable to anyone, they won’t be held to account and no-one will be counting on them.

Responsible: As a “grown-up”, I act responsibly. If I see a banana skin on the floor, I pick it up and put it in the bin, so no-one slips and breaks their neck. I wasn’t “accountable” for the banana skin; I merely acted responsibly i.e. as if I was the cause.

We all need to work together in programme and project teams and often are “counting on each other” to deliver or do certain things. If I spot something wrong in someone else’s area, I shouldn’t just ignore it, just because I’m not accountable. I should let the “accountable person” know and even offer to help them solve it, if I have the knowledge and skills needed. In programme and project teams we all succeed or fail together.

So let’s look at this in the context of a programme or project and see how this works.

The person who is accountable is not necessarily the person who does the work, but the one who sees that it is done. This is useful in planning projects. You should be familiar with the accountabilities of the project sponsor and project manager. The project manager is accountable to the project sponsor for managing the work on a day-to-day basis, ensuring the deliverables are in place at the required time, quality and cost. He or she cannot do it all, or in many cases manage it all. We all should also know how a project should deconstructed into life cycle stages. This decomposition can be followed through with major packages of work being made the accountability of a particular, named, team manager. These work packages may be divided into smaller work packages and ultimately into individual activities and tasks. This deconstruction is called a work breakdown structure. It is fundamental to good governance and planning and also forms the basis of reporting and escalations. So you see, accountability starts at the top and trckles down. If you aren’t clear on accountability, you have no governance in place.

In practice, single point accountability means every task, activity and work package at any level in the work breakdown structure has a person named as accountable for it. This has four advantages:
– It is clear what is expected of each person.
– Overlaps should be eliminated as no deliverable can be created within two different work packages.
– If a gap in accountability appears (due to loss of a team member, for example or a plain error), the next person up the tree is accountable to fix it.
– If scope, cost or time proves to be inadequate to create the deliverables, it is clear who is accountable for raising these issues.

In practice, accountability is shown in the way that project plans (bar charts) are designed. The examples given in the planning chapter (21) in the Project Workout, clearly show accountability.

In programmes and projects it is essential that accountabilities are clearly stated and are unambiguous so everyone knows who is called to account and who they are accountable to. Similarly, team commitment should be fostered, which promotes responsible and open behaviour by all team members. Knowing who is accountable is not about placing blame (blame games seldom achieve anything but angst), it should be about clarity over who is doing what and knowing who to talk to.

For more on accountability in The Project Workout 5th edition, Chapter 15.

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 5th edition

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

Where to find more in the Programme and Portfolio Workout 1st edition

Chapter 3 puts projects in the context of programmes and portfolios.

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 5th edition
Chapter 20 covers schedule planning.
Chapter 25 deals with change control.

Finding help in the Programme and Portfolio Workout 1st edition
Chapter 22 covers planning.
Chapter 23 deals with change control.