Time for another quick guide to project management blog postings made recently. Given we’ve just been looking at project planning, it is serendipitous that there have been a few posts out there on assumptions.

You definitely need to pay attention to the assumptions you are making when you are planning. As we will see in our next project management guide on scheduling, you must capture them in the process. Making sure you do this gives you a number of advantages. Kent McDonald’s post, Assumptions, Communication, and Donkeys on the Project Connections blog highlights this, and what you should be doing with these assumptions once captured.

As Kent says, one of the things you must do is revisit the assumptions regularly. The environment your project is in will be continually evolving, and those changes may effect the veracity of your assumptions. In addition, it may turn out that an assumption that everyone thought was right turned out to be wrong, even without the environment changing – it just took time to come to light. John Reiling has a post at the PMCrunch blog, Check Your Assumptions, that discusses this in more detail.

Finally, you need to check you are actually capturing all of your assumptions. We all make assumptions in our day to day life that we never consciously recognise. This often happens when we are in a situation we think is the same as one we have previously been in. Unfortunately, because we don’t consciously think about these assumptions, we don’t give ourselves a chance to verify them! Pawel Brodzinski at Software Project Management has a good post, Avoid Unconscious Assumptions with some useful examples of this.

Hope you’ve found this round-up useful. See you again on Monday!

In our last Project Management Guide (Planning the Planning – 2) we looked at all the areas of the project we will need to cover in our project planning. Now it is time to get on with it.

Firstly, I need to make sure we are all on the same page when it comes to what a plan is. Many people (and a distressing number of project managers, too) think only of a Gantt chart when they think of a project plan. You may recognise it as what you get from Microsoft Project. This is better called a project schedule, in that it shows when we expect the various sections of the project to happen. We’ll come back to this later.

What we want to have in our project plan is:

• Aim of project
• Outputs
• Quality criteria
• Resources
• Management structure
• Milestones
• Tolerances
• Dependencies
• Risks
• Schedule

Let’s have a look at these in turn, and see why they are needed, and what we want to achieve with each of them.

Aim of project

What do we want to produce? You’ll recall that we have looked at the reasons for doing the project, and the benefits expected, in Building the Case. (Take a look at the Business Case template (PDF) to refresh your memory.) The aim of the project is a mixture of these. This section of the plan can be either fulfilled by linking to the main Business Case, or by restating it in language for the expected audience. For example, your business case may have been written for high level approval in your organisation. You may want to now put it in terms the project executive expects.

Outputs

Given the aim of the project, what do we actually need to produce to get there? What will your completed project be made up of? These need to be clearly defined. For example, your project’s aim may be to upgrade the IT infrastructure in an organisation. Your final output would be a completed computer network, a new computer on every desk, and all appropriate software installed and ready to go.

Quality criteria

Now we have the outputs, we need to understand what quality they need to be of. In the example above, we have an output of a completed computer network. However, we need to know that the network can actually cope with the amount of traffic going over it!

This means we need the completed output to be of a certain quality, and we need to define what that quality is. These targets tell you what success is, what completion of the project is. They need to be SMART:

• Specific – Clearly defined and precise
• Measurable – e.g. not “new computers”, but “computers with 2Gb of memory”, etc.
• Attainable – Don’t ask for the impossible
• Relevant – Is the criterion actually related to the aim of the project?
• Time-based – Enough time to achieve this. There is no point expecting a year’s worth of work in one week!

It is important you take some time with the stakeholders in your project to produce this list. The final customer of the project will naturally be very involved, but don’t forget your business head – don’t promise everything without considering the costs. Your project executive, and a representative of those who will be doing the work, will have major inputs into this also.

Finally, you will also need to decide who has the final say over the quality of the outputs. Hopefully your work on defining the quality criteria will mean there are no arguments over the quality (i.e. no qualitative judgements, only quantitative) but you need to make sure you schedule in time and people to do the evaluation work.

Resources

We have now set down what outputs we need to produce, and what quality they need to be at. This means we are now in a position to look at the resources we will need to achieve this. Resources include staff time, particular knowledge or skill sets, money (e.g. buying equipment), and time (some tasks can’t be increased by throwing more people at the problem, e.g. delivery times, setting time for concrete, etc.).

Management structure

How are we going to manage the work? You need to describe the general approach to the project here. Who will be the decision makers for the various different streams of work? For example, you may be doing a significant procurement – who makes the decision about what company to buy from?

How will we share progress on the project? Who will we share it to? For example, you may decide to have regular project team meetings – who needs to attend? What level of information will you be sharing? Who else needs to be kept informed, at what level of detail, and how often? For example, you may want to keep the project executive updated at an overview level of detail on a weekly basis, while you keep other managers appraised at a higher level of detail.

You will also need to spell out the relationship of yourself to the project executive, in terms of the monitoring of progress. Equally, you need to put down how you will be monitoring progress of the allocated tasks.

There is no one right answer for how this should be done, and indeed it will vary with every project. Make sure you think about the size and complexity of the project, and also the organisation’s ethos and current management style.

Milestones

Here you need to think about how you will break up the project. Unless it is very small, you don’t want to have the entire project as one lump of work, with the only check on progress at the very end. Instead, it makes sense to break the project up into discrete chunks, where related tasks can be lumped together, with a sensible milestone at the end of them. For example, in the technology refresh in the example above, you may want to break the project down into something like:

1. Requirements gathering
2. Tender writing
3. Tendering process
4. Contract negotiation
5. Deployment
6. Testing

It makes sense to have a defined milestone, so you know when each section is completed. There is also another benefit of breaking the project into chunks, which I’ll come back to.

Tolerances

You will have already looked at the resources you need. Now we need to set how far you, or the project executive, can let the project stray from these targets before needing to sound the alarm. For example, you could set a tolerance in terms of finance of +/- 5%, and a tolerance in terms of time of +/- 10%. Equally, you may want to look at tolerances of quality – i.e. how far from the quality criteria are you willing to accept?

It is remarkably unlikely that a project will not deviate from its resource or quality targets. Setting tolerances allows you to be able to manage the project without continually seeking guidance from the project executive as to whether you should carry on. This is not to say that you should be happy with these deviations, and you should try to avoid them, and monitor them closely. That way you can build your understanding of the project for the future.

Dependencies

This is where you look at what needs to happen before something else. For example, in our example above, you need to complete the requirements gathering before you can finish the tender documentation. You need to start thinking about the dependencies so you, and the project team, can understand the impact of changes in any part of the project.

These dependencies should include both those internal to the project (i.e. those under your control), and those external to it (i.e. those outside of your control). For example, you may need an accurate figure for the number of staff in the organisation. This needs to come from your HR department, and would be an external dependency.

Risks

Simply, what could go wrong? What could happen that would damage your ability to deliver the project? Are there things you can do to avoid them, or minimise them?

Scheduling

This is the Gantt chart-style information that many people envisage when a project plan is mentioned. In this, you need to put down what you expect to happen when. It will include your dependencies, milestones, and probably resources. At this point, it will be a relatively high overview of the whole project.

There is something you need to understand about this schedule, and that is this: it will be wrong.

I know that seems a strong statement, but it is vital that you understand that you cannot make a perfect schedule. You really would be getting into the realm of prophecy if you think you can sit down now, and accurately and precisely pinpoint the date the project will end. No, what you need to do here is achieve the possible.

The schedule needs to include the overview, with the project broken down into sensible chunks. This is the other advantage of breaking the project into chunks we mentioned above. By having the project broken up in this way, you will be able to start planning the first section in quite some detail, extending out for a few weeks. But from then on, it will start to be based more and more on blind guesswork and faith. Don’t try to be artificially precise – keep it vague, use rough figures.

As you come to the end of each chunk of the project, you will be able to plan the next one. You can use the information and experience you have just gained from the previous section, and thus you will be able to be more confident.

Make sure you explain this to your project stakeholders! Often your project executive may look at a schedule, and imagine everything is laid out and known. You must get this idea out of their head straight away! Explain that the early part is firmer than the rest, and make sure they expect changes as the project moves on.

Your boss will crave certainty, and absolute dates for the project, from the very beginning. You must resist the pressure to name a specific date, and explain why. While there may be a temptation to give an answer (no doubt of a date plucked, essentially, from the air) you need to instead be realistic about what is and isn’t possible in terms of scheduling. Anything else can only lead to trouble for you, the project, and ultimately your boss further down the line.

Now we need to do all this!

Phew! That’s a lot to fit into a plan! But don’t worry, you won’t be doing this alone.

You see, you cannot know everything you need to complete the plan, and you shouldn’t expect to. I’ve mentioned bringing other people in to decide what success looks like, and it is vital that you bring people in to help with the scheduling. You will have a project team who will be doing the work, and it is probable, if not certain, that they will have a better idea than you of how to break down a chunk of work into specific tasks, and how long those tasks will take. Make use of their knowledge! This has the added benefit of bringing them into the project, and helping to start the process of turning a group of individuals into a team. In the next section of the Project Management Guide, I’ll be looking at some of the techniques and tips to carry out successful scheduling meetings.

That’s my idea of what is needed in a project plan. What have I missed? Do you include something else? Or do you manage with much less? Comment below and let me know!

Project management certification is a tricky subject. There is no doubt that there is a significant amount of value in some certifications, less in others, and some are just not worth it. Today, we’re looking at project management certification and training on Project Management Guide, with a round up of a few posts and articles.

Firstly, we look at Myths of Project Management Certification Debunked by Wayne Botha. His 5 myths hit the spot, particularly number 3: “Certified project managers are always more effective than non-certified and experienced project managers.” While certifications are nice, they are not the true measure of a project manager – only the track record of their projects can be that.

That is not to say there is no point in getting some certification. As John Reiling puts it in Top 10 Benefits to Earning a Certification, ‘While it is said that “experience is the greatest teacher,” a certification “rounds you out.”‘ This is very true. While you will need considerable experience to help you in your project management, sometimes you will run across situations or issues you simply haven’t seen before. As well as applying your experience, it is useful to have some practical advice from elsewhere to fall back on.

It is important, however, not to get too hung up on having a methodology. As Joseph Phillips says in Project Management Models, Certifications and the Pyramids, “here’s what I think: project management is project management. I don’t think it matters what approach you take to complete your projects, as long as you complete your projects.”

Project management is too complicated to boil down to just one set of processes, a book of templates to fill in for each project, or a series of steps to take on every project. It involves hard work, soft skills, a logical mind and a creative spirit. These take time to develop and nurture, and while a particular certification path or methodology will provide you valuable pointers and help, ultimately it is down to yourself to make sure you have the right skills and attributes to deliver your projects on time, and on budget. Certification is one of the pillars that will support you in project management, but it isn’t a magic bullet.

So get out there and yes, read the books, follow the courses, take the exams, but, most importantly, do the work as well!

Just a quick one today, with some more information on the importance of your project’s business case.  As you will recall from Building the Case, the business case should explain why you are doing the project.  This is vital moving forward, and needs to be revisited often throughout the life of the project.

PMHut has an article called Writing an Unbeatable Business Case which gives the PRINCE2 thinking behind it, which I personally find very useful.

Don’t forget you can also download my Business Case template (PDF) to get you started.

Just to show it’s not just the British government that doesn’t seem to handle projects well, I thought I’d post a quick story about the FBI’s new case management system.

While it is currently ‘only’ expected to be $26 million over budget and 6 months late, it is also a replacement project for one that cost $170 million that was abandoned as it was “obsolete and riddled with problems” – so not quite so good.  However, scrapping a project which isn’t going to deliver what you need (instead of letting it drift onwards, not wanting to take the hit for stopping it) is actually good project management, so the FBI get points for that.

Unfortunately, the Justice Department’s inspector general’s report (PDF) says the FBI:

“needs to improve the risk management process it uses to identify, monitor, control and mitigate risks before they negatively affect [the project’s] cost, schedule and performance”.

We now have a project management team and structure in place.  We’re agreed we want to move ahead with the project idea.  We need to put in place what we need to actually carry out the project.  In the previous post in the project management guide, we realised we needed to make sure we planned the project well – and the best way to do that was to plan that planning process.  Today I want to expand on the kind of things we need to make sure we do in the project planning – in other words, what we need to put into the plan for the plan, what we need to have in place so we have the best chance of beginning a successful project.

What do we want?

Earlier, we have created a business case for the project.  This is what we had our project executive agree to, and is the reason for doing the project.  When we move on to the planning of the project, we will start to have a better idea of how much this is likely to cost – which means we must revisit the business case.  In addition, we will also start to get a better idea of what we need to do to achieve the project goals, and we need to expand the business case to include this information.

Here is a Business Case template (PDF), which shows you what you need to start thinking about at this time.  The first four sections of this can be filled in now, at least in some way.  The second four sections we can start to populate once we move into project planning – and that means we need to plan to do this in the next phase of the project.

In that next phase, we also need to come to an agreement on the quality we want the end product to have.  Partly this comes down to a trade-off between time, money, and quality.  However, we also need to look at what is expected at the end.  For example, in a software project, we may only be looking for a proof of concept, or a prototype system, as opposed to a completed package which is ready to be sold as commercial software.  We need to get clear agreement on this at the beginning.  We also need to put down some ground rules on how the quality will be assessed, and by whom.

Finally, we’ll also need to come to an agreement on various project management ‘house-keeping’ issues.  Who needs to know project progress information?  How often?  What level of detail?  What form should this take (e.g. meetings, formal documents, emails, phonecalls, etc.)?  Who will make the decisions about the project?  This isn’t the day to day matters, but the bigger decisions about quality, budget, acceptance of products, and so on.  We have a project executive, but who will also be involved?

All of these issues will need to be considered and decided on in the next phase.  And on top of that, of course, we will need to start to plan the actual project work!  Make sure you realise what an important phase the next one is.  It is the foundation on which the rest of the project rests.  If you get it right, and put in place a clear plan, achievable and desireable objectives, with a strong project management structure and team around them, you will be well on the way to delivering a successful project.

I hope this second ‘Planning the Planning’ post in this project management guide has been useful to you.  What else would you include in the project planning phase?  What tips and techniques have you found useful?  Post below!

Oh, and Happy New Year!

(Image courtesy of perhapstoopink. Some rights reserved.)

As a follow-up to the news reported in The importance of project management, (which was also picked up by CIO, Silicon.com, ZDNet.co.uk, and Ron Rosenhead, among others) it turns out the UK government’s Department of Transport are not the only branch of government failing at project management.

The UK’s National Audit Office has looked at 20 of the largest projects in the Ministry of Defence. They found the projects were on £205 million over budget and 96 months later than initial estimates! Tim Burr, who is the head of the National Audit Office, said:

“Performance remains variable and, until the MoD and the defence industry improve their decision-making processes and show sustained learning from previous projects, value for money will not be consistently delivered.”

To be fair to the MoD, many of these projects are procuring cutting edge technology, and you would expect some problems. However, as the Financial Times reports, the NAO “identified key failings, including shortcomings on project management and the department’s failure to act as an intelligent customer.” That, combined with an apparent ‘lack of realism’ suggests the MoD needs to look again at its project management.

On the last Project Management Guide, we looked at building the business case. Now we have a clear idea of what the project is for, and what it should achieve, we need to look at what we need to get a clearer idea of how to go about delivering it, and how long this may take.

This is not the same as planning the project itself. What we are doing here is having a look at what kind of resource we need to set aside to do that planning. Now, in a relatively small project, this should not take very long at all, and any reporting to the project management team we have created can be informal. However, for some projects, even the work of planning the project is a significant exercise.

For example, imagine a project to design and produce a prototype of a new aircraft. There are a huge number of factors to take into account, and the planning for that project could be considered to be a project in its own right. In that case, it is only sensible that you consider the resources you will need to get it done.

Once you have produced this plan, it is back to the project management team you have put together, especially the executive, to get their approval to move forward. This takes us beyond starting up the project management process, and into building the framework for the project work.

You may ask why we have spent so long in making sure we have a project management structure in place. In practice, this stage can often be very short, but you really shouldn’t be tempted to skip it. The right project management team, and particularly the right executive, can mean the difference between success and failure. Showing the right discipline now in the processes used gets everyone into the right mindset for the project as a whole. And making sure the business case is known and agreed makes sure you know what a successful projct will look like, and what you need to check throughout the project to make sure you are staying relevant to the project and the business needs.

Just in case you were in any doubt about how important good project management is, take a look at the lamentable mess a department of the UK government made of a recent project.

It was an IT project, merging a variety of separate systems into one. With an original budget of £55m, it was supposed to save the department £112m when complete. In fact, it is likely to cost £121m, and save £40m – a nice £81m cost to the taxpayers of the UK!

More information is available from articles in two UK newspapers, The Guardian and The Daily Telegraph.

The Telegraph article has a quote from a British politician who looked at the project:

“The Department must also overhaul its project management capabilities, closely examining the expertise of its project managers, setting up systems for subjecting future plans to rigorous challenge and, crucially, establishing incentives to officials for success and penalties for failure.”

While most errors in projects aren’t as high-profile as this, they could all cause serious problems to your organisation. With a strong project management team, methodology, and skills, along with an organisation truly bought into project management, perhaps this project could have been given a chance of success. That’s why it is important you develop your project management skills, and keep them up to scratch, with project management resources such as this project management guide!

In our last installment of the project management guide, Laying the Foundations, we looked at putting together the project management team. The most important task for this group now is to expand on the project mandate or idea that has started this whole process. They need to make the business case for the project.

So what is the business case? It explains the purpose of the project, the aim that it has, and importantly, why the project is a good thing for the organisation to do. Let’s look at an example.

Wally’s Widgets is a firm on the up. It is currently based in a single floor office above a store in a suburb. However, things are getting a bit cramped. The firm has recently taken on a few new staff, and it’s getting hard to fit everyone in. In addition, their landlord has recently put up the rent for the space. So Wally’s Widgets has decided to move to a better location.

The project management team have come together to write the business case for the relocation project. Now, some of this is simple to write. What the business wants to get out of this project is obvious – more space, and hopefully paying less rent. But we need to drill down to show why the business wants these things. Firstly, the business wants more space to provide a better working environment for staff, and to provide the possibility of future expansion. Secondly, the business wants to reduce rent as this has a direct impact on the bottom line!

It is important to realise that these reasons need to be put down, because the business case should be revisited often throughout the project. This is because it is important to continue to check that the project is still relevant. For example, Wally’s Widgets could hit a bad patch, and have to lay off some staff. Then the need for extra space is lost.

The need for a strong business case for a project is particularly acute in times of economic stress. As you can see in “Recession may put short-term IT projects on hold” and “Surviving IT Project Management Complexity”, the business case becomes vital for deciding which projects survive, and which projects can be cut. You must always make sure your business case is as strong as possible – and, if the situation changes around you, examine it with an open mind to see if the project should be stopped.

(Image courtesy of Jacob Bøtter. Some rights reserved.)