Job Done

I started this blog as an experiment in writing a book, bit-by-bit. It has been a long journey, but a couple of months ago I published the book: How to Plan Small Projects. I hope that if you have been following along, or if you come across this blog and find it useful, you will purchase a copy.

There are two 'book trailers' at SlideShare.com - click here.

You can buy the book at Lulu.com - click here.

Kind regards,

...Geoff

Naming Projects

There is power in a name.

People know a project by its name.

A project name needs to (a) explain what the project is about; and (b) distinguish it from other things which are not the project.

Many projects have two names - the organisation's name and the name people use (aka colloquial name). You are seldom able to completely contral the colloquial name. Generally the colloquial name is the one which will persist. If you have sufficient influence, consider making the colloquial name the name for the project.

You can also have both a short name and a long name. The short name may be a couple of words or an acronym or some other abbreviation - this is a good way to keep the organisation's name and the colloquial name closely aligned.

Systems projects tend to be named after the system which is being built. Which is appropriate. Although confusion can sometimes occur. When the longer titles are used - The Blah Blah Project and the Blah Blah System - things are OK, but when both are shortened to Blah Blah, there can be issues. Although practically speaking this is only a minor risk.

...Geoff

The One Page Project Manager (a slide show)

Using The One Page Project Manager

View more documents from Geoff Higgins.

Project Outcomes

In addition to achieving the project objective, there are generally a range of project outcomes, both positive and negative. For example, the organisation may have purchased a technology for the project which is useful for other tasks; or through the changes implemented on the project people are freed up to do things they had not previously done.

It is good practice to predict what these could be. These predications can then be used to promote the project to people for whom the main project objective is not particularly attractive.

Project Deadline

By definition projects are expected to finish. In most cases we have a good idea of when that will, or must, happen. At this stage you have not developed a rigorous project schedule, but you have decided what the key activities will be, and how much you are likely to be spending. You should be able to take a stab at the project end date.

If you are going to be presenting this information to people who are likely to treat this finish date as a commitment, make sure you add some time. This is another kind of contingency – in this case a time contingency as opposed to a cost contingency.

The reason why you add time is that projects seldom finish early (unless timeframes have been poorly estimated or you have done less than you expected). They are much more likely to run over time. We often identify tasks that we did not think of before we started, or we decide to do more than we had planned. (This is called 'scope creep' and is considered a no-no in sophisticated project management circles.)

Project Budget

There are lots of different kinds of costs – fixed and variable costs, operational and capital costs. In planning project costs for small costs I like to distinguish between ‘cumulative’ and ‘lump-sum’ costs.

The cumulative costs are those that increase as you do more, or as tasks take longer – for example, when you are paying a contractor an hourly rate. The lump sum costs are those that will cost a particular amount – for example, when you have a quote from an electrician for lighting and power points. Lump sums can vary, but generally only under particular recognisable circumstances, such as when we later ask the electrician to add a new safety switch to the fuse box. In this case the electrician will have a legitimate reason to ask for more money.

Wrapped up in the need to budget is the need for a source of funds. Identifying and making firm friends (or at least developing a grudging mutual respect) with the person through whom you obtain the funds is very important.

You need to ensure that you can afford the unexpected – such as the people you are paying an hourly rate taking longer to get things done than planned; or needing to/wanting to do some things you did not initially put in the budget. You can do this by going back to the source of the project funds and asking for more money. Alternatively, you can add a contingency figure to the figures in your budget. This is generally to cover for small additional costs. A project managers’ rule of thumb is to always add 10%. If you have reason to expect to need more, you can consider adding more. But remember that a high contingency may stand out, and need to be justified. A really high contingency may prevent the project from going ahead (which may be the best outcome if the chances of cost overruns are high).

Microsoft Excel (or other spreadsheet program) is a good place to record your budget, although you can equally use a pen and paper (and calculator if needed).

Project Monitoring

This is a long one. Bear with me, as it will be worth it. Project monitoring is often the difference between ‘on time and on budget’ and ‘late, costing way too much and not having warned the people affected’.

…Geoff

To reduce the risk of the project going substantially over in terms of time or cost, you should monitor project progress.

Regular reporting of progress to people with an interest, including the project team, can keep you focussed on project monitoring. Even if progress reports are not requested, they can be a good way to promote the project if it is going well, and of communicating issues if it is not going so well.

A fortnightly progress report will typically consist of:
* Current Tasks – A short list of tasks currently underway.
* Project Progress – Stating what has been completed in the fortnight just ended; and what is expected to be completed in the next fortnight.
* Variation – An explanation for how the budget, workdays and/or timelines have varied from the original plan (whether positive or negative).
* Issues – A brief description of any significant issues, including the action being taken.


To ensure that members of the project team take responsibility for monitoring their own progress, request mini-status reports. At the least this could be an email or jotted down note that includes:
* Current Tasks – A short list of current tasks, so you know what they are doing at the moment.
* Project Progress – A list of what the person has completed in the fortnight just ended; and what they expect to complete in the next fortnight.
* Variation – An explanation for how their tasks have varied in terms of starting or finishing early or late, and where tasks have taken more or less time than expected.
* Issues – A brief description of any issues affecting the individual, including the action being taken.

The topic on project scheduling below introduces the concept of milestones. For now it is important to note that the achievement of a milestone is a good time to think about how the project is progressing, what has been learnt so far and what is still to be achieved.

There must be a way to report issues and catastrophes which is separate to the regular reporting cycle, as issues and catastrophes are generally too urgent to wait for the due date for the next status report. Open lines of communication are important. It is also good practice to expect people to be able to describe clearly and succinctly:
* What the issue is.
* What impact it could/will/has had on the project.
* What could be done to resolve it (multiple alternatives).
* What alternative is recommended by the person raising the issue, and why.

In addition to monitoring time and cost, you should be monitoring the ‘quality’ of the project’s performance. This often involves scrutinising project deliverables as they are developed. When this is the case, these ‘review’ steps need to be incorporated into the project activities, to ensure they are not overlooked.

The most important thing at this early stage of the project is to decide how you will monitor the project, otherwise there is a good chance you will start the project without monitoring progress at all.

The Lichtig Score (Project Teams)

Occasionally I would like to present what others are saying on topics of interest to me. These topics may become sidebars in the book. (Yes, for those new to this Blog, I am writing a book - that is the point of all this.) Here is a bit about something I read this week.
...Geoff

Will Lichtig, an attorney who specialises in construction projects, recently wrote an article called 'Projects as Patients: What Can We Learn from the Medical Profession?' (the original is at projects as patients - in the American Institute of Architect's journal Practice Management Digest). In this article Will is concerned about construction projects' failure to keep pace with the increases in productivity elsewhere in the economy, and their failure to keep people safe. He calls projects 'temporary social organisations', and proposes a project management equivalent of the Apgar score given to newborn babies. He believe we should closely examine five aspects of projects: collaborative planning; reliable promising; unaccounted-for foreseeable issues; safety; and project mood (or team spirit). You can give a 0, 1 or 2 to a project on each aspect - see Will's article to find out what each rating represents. Alan Mossman, posting on the Blog Reforming Project Management calls Will's system the Lichtig Score.

I am impressed with the apparent simplicity of this rating system, as it has the potential to provide the tools to substantially improve the experience of people on project teams, while improving our chances of achieving our project objectives.

I suggest that you try this system out on a project you are familiar with. I then suggest that you apply another deceptively simple approach to understanding the causes of both excellent and appalling ratings - the 5 whys approach - ask 'Why?' five times to get to the bottom of what we are doing both right and wrong.

Then you will need to have the courage to share your findings.

Project Team

The people needed result directly from the project activities and hence the Project Objective. You need to identify ‘project roles’ and match ‘available people’ to ‘project roles’.

Identifying ‘project roles’ involves using the project activities to decide what jobs will need to be done, and what kinds of people are needed to do these jobs. When the ‘available people’ do not match the ‘project roles’ you need to try to expand the pool of available people and/or turn away people who are not expected to make a worthwhile contribution.

There are many things that you could record about the people and roles on your project. Some useful things include skills, preferences, availability and cost.

We need to know their 'skills' so we can determine whether they can do the job that needs to be done. People will often work harder on tasks for which they have a 'preference'. Where people are operating away from their preference, you are likely to need to work harder to motivate them. 'Availability' is critical, as progressing the project efficiently involves keeping to a schedule of work. In some cases this will need to be altered to accommodate availability. In many cases there will be a 'cost'. You need to know this, and to take this knowledge and enter it into the budget you have already produced (see 5.5 Project Budget).

There are two intangible factors that can have a huge impact on project success: willingness/ability to learn and ability to work in a team environment.

'Willingness/ability to learn' is often critical on projects, as it is far easier to move people between tasks than to move people into and out of the project, and possibly back into the project later. Instead we try to do as much as possible with the people we have.

The 'ability to work in a team environment' is also critical, as the project environment is often a hot-house environment where lone wolves and solitary wombats are unlikely to thrive.

Selection for willingness/ability to learn and ability to work in a team environment is a difficult task, but far easier than getting people who do not have these attributes to work cooperatively on you project.

Project Activities

This is really just a cursory look at what needs to be done on the project. You will plan what needs to be done in much more detail later, when you develop the Project Schedule.

In planning for the project, it is useful to have a broad understanding of what will be done, and to continue to build on this understanding as your plans progress. If you start this now, when you come to write the Project Schedule, you will already have a lot of the content of the schedule. For now your list of activities may be quite basic, or extremely thorough. Either way, keep in mind, these are the activities we expect to accomplish. They are not necessarily all of the ones we will accomplish.

Depending on the size of your project, you may want to identify all of the activities now, or you might want to note the really important activities the project will involve. At the very least this is a good time to write down what you need to do to get the project started, and what you will need to do to get it finished, other details in between can be filled in later.

Bad Clients

Not all clients are created equal. Sadly some clients are not committed to the project – they may have other priorities, or even see the failure of the project as desirable. They may vacillate between commitment and complete ignore. If you have a bad client you should make a choice – to stay and make the best of the situation, or to go. If you choose to stay, you may be able to promote the project to the extent that it becomes a priority again; but if you do, you should not assume this will stay a priority without constant attention from you. You may be able to promote the project to someone else, perhaps securing their commitment and supplanting the bad client with a good one. You may just find that you are hung out to dry.

Sign-off seems pretty easy, but gaining sign-off often involves buy-in. Certainly the accomplishment of the Ultimate Objective involves buy-in.

We generally achieve buy-in by either directly involving people in the project (if not all people affected, certainly a significant number of ‘thought leaders’), or by ensuring that people cannot live without the results of our project. The latter is far less common than you would think, so as project managers we generally rely on people’s involvement to secure their ‘buy-in’.

The Project Client

You need to know who you are doing the project for, and what involvement that person or persons may need to have in order for the project to succeed. Enlightened project managers seek both ‘buy-in’, ‘agreement’ regarding significant decisions, and ‘sign-off’. In some cases, you are the client. If that is the case, this topic needs little attention. If not, read on.

Although you can generate some ‘buy-in’ by promoting the project to the client, and encouraging their involvement, be very cautious if you have to work too hard at this. It is better to have no project than a project with no client.

There will be many important decisions in the life of a project. Running decisions past the client can avoid costly rework and a loss of the confidence of the client. If a decision is needed, but there are no compelling reasons to go one way or another, the client can be invited to make a decisions with minimal risk to the project. Where there is risk to the project of a poor decision, you may need to spend considerable time promoting your preferred outcome.

Sign-off is the approval of the client. If you are the client, don’t worry about this. If someone else is the client, you need their approval. Rather than leaving this to the end of the project, it is sensible to seek approval at regular intervals – commencing with the Project Objective or the Project Definition, or maybe even commencing with approval to spend time writing the Project Objective and the Project Definition.

...Geoff

The Project Objective

The project objective should answer the question: “What do I want to achieve/avoid through doing this project?”

There is a simple rule you can apply to ensure you have rigorous and complete project objectives. This is known as the S.M.A.R.T. Model. SMART is an acronym for Specific, Measurable, Achievable, Realistic and Timeframes.
Specific Clearly states what must be achieved.
Measurable Clearly states how success will be measured.
Achievable Is realistic in terms of effort and expenditure.
Relevant Meets the organisation’s strategic plan; contributes to achievement of a significant venture.
Timebound Clearly states start and end times, and downtime if appropriate.
(Cost You may wish to add roughly how much will the project cost.)
Of the above five components of objectives, Achievable and Relevant are not always documented, although you must ensure they are taken into consideration in writing the objective.

Project Objective Example – The Garden Shed
(As I have no room in the garage for my gardening tools, I will do the following project:)
To build a two-door garden shed that is 2 metres wide, 1.8 metres deep and 2 metres tall and has two doors on the concrete slab in my backyard. Starting this Saturday morning, and finishing by sundown Sunday. The kit and tools should cost $2,500.
(I am using a kit and have done this once before, so do not expect any major problems.)

Explanation of Example:
Specific … build a garden shed …
Measurable … that is 2 metres wide, 1.8 metres deep and 2 metres tall and has two doors on the concrete slab in my backyard …
Achievable … (I am using a kit and have done this once before) ...
Relevant … (I have no room in the garage for my gardening tools)...
Timebound … starting this Saturday morning, and finishing by sundown Sunday.
Cost … $2,500 for kit and tools.

The Ultimate Objective

In addition to the Project Objective, in many situations there is an Ultimate Objective. The Ultimate Objective is the objective for which we are undertaking the project. In the case of the building of the Chunnel (the tunnel beneath the English Channel), the Project Objective involved digging a long tunnel and lining it with concrete. However, the Ultimate Objective was linking England with the Continent of Europe, a far larger undertaking that just digging a hole. For some people the Ultimate Objective may have been to improve the links between the United Kingdom and the European Union; or to create a cost-effective method of transporting goods between the United Kingdom and the European Union. Be sure to know and understand the Ultimate Objective.

ACTIVITY:
Take a sheet of paper and write the letters SMART down the left side, giving yourself plenty of space to fill in the details. Fill in the details. Then ask someone to read over the objective - ask for their honest feedback abotu what you have written.

The Project Definition (Applying the 7 P’s)

Earlier I noted that the Project Definition will consist of the following content. I have added some jargon to make it easier to put sub-headings into this topic.

At a minimum, you need to know:
* What you want to achieve – Project Objective.
* Who you are doing it for – Project Client.
* How you will go about it, how you are going to start, and how you are going to finish – Project Activities.
* Who will be involved – Project Team.
* What the project should cost – Project Budget.
* How you will keep track of progress – Project Monitoring.
* How soon you need to/can be finished – Project Deadline.
* How you will be able to tell that you have finished – Project Outcomes.

...Geoff

Project Information

The effective project manager quickly becomes a clearinghouse of important and trivial project information. To be that clearinghouse, first the project manager must absorb a huge amount of information about the project. Even small projects can potentially involve large amounts of information. Some suggested questions you need to answer as soon as possible after taking on the role of project manager include:

* What do we want to achieve from this project?
* How will we know that the project is finished?
* How will we measure success (in quantity and quality)?
* What else could we achieve that may be beneficial?
* What could go wrong during the project?
* Will all of the outcomes be positive?
* What processes should be followed?
* What safety criteria should be considered?
* What impact could this project have on other parts of our organisation?
* What machinery and tools are required?
* Are there in issues with regard to procurement or maintenance of the machinery and tools?
* Who needs to be involved? In providing supplies/inputs, doing the tasks, observing, measuring outcomes, etc.
* Do people need to be released from other duties?
* Who needs to know about the project?
* How much do they need to know?
* How soon can/should we start?
* How soon can/should we finish?
* Will any downtime impact on the project?
* What is the budget?
* Where will the project be located?
* What are the consequences of project failure (for the organisation, the stakeholders, the project team and the project manager)?

Organising this information can be very challenging. If you like mind-maps, this is a great way to organise large amounts of information. If you are a notebook kind of person, get a notebook ASAP and write the project name on the front. Number the notebook “1”, as you are likely to need more. Much of this information will go into your Project Definition.

...Geoff

Learning How to Write a Book

Hi,
If anyone is reading this, they may want to learn how to write a book too. As you can see, I am learning how to write a book by putting my book writing into a blog. In fact, I got started with this whole process by attending a workshop. Robyn Henderson teaches people How to Write a Book. Actually, what I learnt from the day was more along the lines of How to Publish a Book. I know a bit about writing from my work experience, and so needed to know how to publish.

The idea of blogging my way to a book was my own when I started to stall in writing the book. I had made good progress with choosing the content for the back page, and good progress in creating what my school English teachers called an "Essay Plan". However, I was stalled at that point and needed a burst of energy. But I digress...

Robyn Henderson is a publisher and a public speaker. She writes herself and speaks frequently on the topic of networking. She has 'fallen into' teaching people how to write and publish books, and she is very good at it. So this is going the long way around at providing an unprompted promotion of the workshops Robyn runs. For details of the workshops, please go to her website at www.seachangepublishing.com.au and go to the Seminars and Workshops link. If you can get enough people together, you should contact her about doing a special workshop for you and your friends/colleagues.

Good luck with your writing!

...Geoff

Introduction

There are a small number of critical principles in managing projects, and a large number of accepted practices. This book presents all of the principles I am aware of, and as many of the accepted practices as I can cram in – applying the 80:20 principle along the way. The book is intentionally light on theory and heavy on basic things which need to be done to be effective.

Project management is not rocket science. In fact, it is often pretty boring and repetitious punctuated by occasional victories to keep us interested – which from my limited exposure to rocket science is actually what rocket science is really about. So I guess that although project management is not rocket science, it is still quite similar.

You can be a very good project manager if you do the things in this book consistently and creatively. Consistently follow the principles and apply the practices and you will do very well. Apply your creativity to improve on the practices and supplement the principles with new understandings and you can be an excellent project manager.

But remember, the better the job you do as a project manager, the less attention you will get. As a project manager any exposure is certainly not good exposure. Be good at what you do, and the people who need to know how good you are will, and the others don’t matter anyway. This is not a book on how to get to be the CEO, it is simply about succeeding in the role of project manager. (If you want to be the CEO, I would advise that you read something else.)

Seize the Day (Just Do It®)

The converse argument to my 'lead time' post is the importance of actually doing something. Many projects are good idea going nowhere. If you want your good idea to go somewhere, you need the project to get underway. The purpose of your lead time is to make appropriate preparation for the project. If the project never happens due to indefinite lead time, you have wasted your time.

If you are concerned that the project is too big, and that is holding you off from starting, you might want to consider the potential for a pilot trial (a little implementation that mimics the actual project outcome), or starting the first few activities, if you are confident that you will learn enough to continue the project. Do this with caution, as projects can gain a momentum of their own that is unrelated to the relevance or value of the outcome.

Lead Time - We Never Seem to Have Enough

Hi,
Here is a quicky - a sidebar regarding lead time. There is another one following about avoiding excessive lead time - we project managers need to be able to find a balance between each.

...Geoff

CONTENT:

Much of the pain we suffer by ignoring the 7 Ps can be attributed to the compulsive manner in which we continuously persist in going at projects ‘like a bull at a gate’. We do not expect rats in a maze to sit down and puzzle out the problem with which they are confronted, but we should expect it of our project managers. And tragically, many people who profess to expect it of their project managers continue to place undue pressure to start projects well before they and the organisation are ready.

The term ‘lead time’ refers to the amount of time we give ourselves before something is to happen to prepare for it to happen. When we talk about project lead times, some people persist in saying, ‘we know what needs to be done, let’s get on with it’. What they usually mean is ‘I think I know what needs to be done; and I can’t be bothered taking the time to write it down and I can’t be bothered making sure everyone else knows what I know’. This is fine if you have no stakeholders and the outcome will not affect other people, or if the job is simple enough to get away with not planning.

The bottom line is, we need plenty of time to plan projects before we start projects. If you are not sure how much lead time to allow, take a guess and double it. If you are going to select a Project Manager during the lead time, add the time it takes to get a Project Manager to the lead time too.

The 7 Ps

Hi,
This topic is all about getting some key things done before the project starts properly.

CONTENT:

My friend Michael introduced me to the concept of the 7 Ps more than 15 years ago. Often people ask me how they could have prevented the problems they are currently experiencing, and I find myself telling them about the 7 Ps. Sadly the 7 Ps is one of those concepts often labelled ‘common sense’, but less commonly applied.

(Caution, minor expletive follows.) The 7 Ps are Prior Preparation and Planning Prevent Piss-Poor Performance. For those of you of a sensitive persuasion, you can drop the word ‘piss’, and the point can still be made.

At a minimum, you need to know:
* What you want to achieve.
* Who you are doing it for.
* How you will go about it.
* Who will be involved.
* How you will keep track of progress.
* How you are going to start.
* How soon you need to/can be finished.
* How you will be able to tell that you have finished.

When you put these together, you will have a Project Definition.

If you are wondering what else could be handy at this point, you could find out:
* Whether your organisation has the will and the capacity to complete the project.
* Who can help the project to succeed, and how.
* Where the project will be undertaken, and whether this is the best place/space.
* How the resources you need can be secured by the project. (Resources include cash and people, and possibly other things.)
* What the known risks and issues are and how you will address them.

You can add these to the Project Definition to make it even more comprehensive.

Some people make a Project Schedule part of the Project Definition, but this will be described later.

...Geoff