Friday, February 22, 2008

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).

Wednesday, February 20, 2008

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.

Tuesday, February 19, 2008

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.

Saturday, February 16, 2008

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