Estimating how much work there is in the project, and how long each part of it will take, is a vital skill in project management. You can’t sensibly manage a project without having at least some idea of how long you think each piece of work will take!

But, of course, it’s practically impossible to sit down at the start of a project and pronounce when it is going to finish. Issues crop up, the environment changes, tasks take longer than you thought, and so on.

I’ve already written about the scheduling process for a project. This should help you arrive at a list of tasks. These are your starting point for estimating.

Because you have a list of tasks, you are able to begin estimating the length each one will take. Immediately, this is more useful than trying to estimate the length of the entire project, or major sections of it. Bringing your thinking down to the level of specific tasks makes it much easier to mentally grab hold of the work, and have a sensible idea of how much time is involved.

(This also works as a sanity check on your task list – if you can’t visualise what has to be done to complete a task, maybe you need to break it down a little more.)

Remember, you are not necessarily the expert on how long the tasks will take. You have a project team who will actually be doing the majority of the work – use their expertise and their knowledge of both the work and themselves to come up with estimates of how long each task will take.

And don’t forget: you’ll have these estimates wrong. I’ve been using the word “estimate” in this post, but don’t forget the simpler version – “guess”. Yes, you are using experience and knowledge to try and make it a reasonable guess, but it still is one.

It’s a fact of project management life that at the start of a project the estimates will be off. The reason I suggest only scheduling in detail for a few weeks in advance is that you can learn from how far off your estimates are. The accuracy of your estimates should improve as the project goes on.

What about you? What techniques do you use for estimating? Let me know!

I’ve been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

Two weeks ago, I suggested a first project management concept, and last week I suggested a second project management concept.

So far, I’ve suggested that:

• The primary aim of every project is to benefit the business.
• Project management is about making the project environment as stable as possible. What is possible varies.

These suggestions tell us why we do projects, and why we need to manage them. Today, I want to look at the two pillars project management needs to deliver to us. Project management needs both awareness and control of the project. Control is impossible without awareness.

I’ve already spoken about project management being about bringing change into a business, in a limited fashion. In other words, we attempt to control change, to stop it being chaos.

But to be able to do that, to have that element of control, we also need to understand what is actually happening with the project. We need to have an awareness of what is going on.

Without that awareness, control becomes impossible. You simply cannot know what direction you need to steer the project in if you don’t know what direction it is currently going in! You can’t know if your attempts at control are working unless you can see what is happening.

And that brings us to our third project management concept: Project management needs both awareness and control of the project. Control is impossible without awareness.

What do you think? Do you have control and awareness of your projects? Which is hardest to get?

The G20 summit has just ended in London, with an agreement every representative there has signed up to. The leaders of the 19 leading countries in the world, and a representative of the EU, have agreed to collectively contribute $1 trillion dollars for various schemes designed to help the global economy, and to tighten up regulation of the financial industry.

Now, I’m not going to try and critique the agreement, or pronounce on whether or not it will be successful in helping the global economy. For one thing, I’m not an economist – and not even economists seem agreed on whether this will help or not. More importantly, that isn’t what this blog is about!

Instead, I want to look at something we can all learn from – the process that the UK Prime Minister, Gordon Brown, seems to have gone through to try and get an agreement. (Well, not just him – mainly his staff and officials, but you know what I mean.)

Negotiation is something we all have to do in our jobs, though I’m assuming generally your negotiations don’t have quite as much impact as his…

What did Gordon Brown do to get agreement?

First of all, he had to clarify to himself exactly what he hoped to achieve. In this case, he obviously had to work with a wide variety of experts in the subject matter. His time as the Chancellor of the Exchequer (the UK Finance Minister) presumably meant he had some experience, but he is a professional politician, not an economist.

But his experience in this area means that, if nothing else, he already had a circle of advisers he knew and trusted, who he could turn to to get the information he needed.

Once he knew what his aim was, Gordon Brown began a tour of many countries around the world. He made sure he visited strategic countries, those who were regional leaders, to both sell his idea to them ahead of the summit, but also to gather information from them, to see what modifications he might need to make to his own position.

This was a vital step – it showed he was willing to be flexible, willing to listen, and willing to work with others to get to a solution all could agree to.

Importantly, one of the main early visits was to the United States. Any agreement absolutely had to have the United States on board, otherwise it would be doomed to fail. Gordon Brown had to make sure very early on that the UK’s aim fit with the aim of the United States, and that the two countries could work together.

After this worldwide tour, the summit itself began. By this point, Gordon Brown knew that his aim was in accord with that of the United States, and knew how close it was to the aims of the other countries who would be attending. His work beforehand also meant he knew what was important to each of the other countries present.

This enabled the horsetrading aspect of the negotiation to work. The final communique is a balance of the positions of the participants. Some things from the original UK position were presumably dropped (increased spending by all countries to stimulate their own economies?) while others were strengthened (tighter regulation of financial institutions?).

By making sure everyone could identify something in the final communique that they wanted to have, Gordon Brown could make sure everyone present was happy to put their name to it, and be seen smiling in the final ‘family photo’ at the end.

So what can we learn about negotiation from this?

Well, we can identify some clear and simple steps we can apply to our own negotiations:

1. Define your position.
   Before you go into any negotiation, you want to make sure you know exactly what you want to achieve. What would be the best result you could hope for? What areas are you willing to compromise on? Which aren’t you? Talk to your own circle of advisers and experts to decide what is important to you, and which isn’t.
2. Understand the position of the other players.
   To reduce surprises in a negotiation, make sure you spend some time gathering information about the likely position of the other participants in it. Sometimes you can only do this by putting yourself in their shoes, and trying to decide what they will be trying to achieve. Other times, you can actually go around and have meetings with them, to listen to their point of view. Regardless of how, always try to understand where they are coming from, and why.
3. Get the most important players on your side.
   If there are key players in the negotiation, whose lack of agreement on its own could scupper the whole deal, make sure you get them on your side early. Going into a negotiation without knowing if the most important person there agrees with you or not is risky at best, and foolish at worst. It may not be possible to get agreement beforehand, but at least make sure your position fits with your belief of what they want.
4. Be flexible to get agreement.
   Play off the various positions against each other. If one aspect is important to one player, compromise on that to gain something from them that is important to you. With a multi-party negotiation, this can become very complex! But because you have gathered the information beforehand about their positions, you will have a clearer handle on their aims, and will be able to plan ahead some of the concessions to make.
5. Make sure everyone can claim a success.
   There are very few negotiations that are a simple battle, that can lead to a winner and a loser. It is better by far to make sure everyone gets something, that everyone can claim the negotiation as a success. By working like this, everyone in the negotiation will be working together to make it successful, rather than having some acting defensively.

By keeping these steps in mind, hopefully we can have more successful, and you never know, maybe more pleasant negotiations in the future!

What do you think? How do you approach negotiations? Do you use the same approach for negotiations internal to your business as those involving someone external, be it a supplier or customer? Let me know!

One of the important skills we need to have as project managers is the ability to handle problems that crop up in the execution of a project. Much as we might work to make sure that problems don’t arise, it is inevitable that something will go wrong. So how do we handle it when it does?

These unforeseen problems are called issues. The first thing we need to do is make sure we capture these issues as they arise. By definition, issues are unexpected, so to make sure they don’t get lost in the rush of day to day events, we need to log them as they arise – to simply write them down, and make sure we don’t forget them.

Next, we need to look at the issues we have captured.

1. What sort of issue is it?
• A change in requirements?
• A problem we didn’t foresee?
• An unavoidable risk occurring?
• A new risk spotted?
• A change in the external environment?
2. What impact is it going to have?
• Will it effect quality?
• Will it effect timescales?
• Will it effect budget?
3. What can I do about it?
• Are there actions I can take as project manager to solve this?
• Do I need to refer it up to the Executive?
• Is taking no action a possible response?
4. What impact would there be in taking action to deal with this?
• What cost?
• What timescales?
• What quality impact?

Depending on the answers to these questions, I may then be able to deal with the issue. If there is action to be taken, and I can do so while keeping within my contingency on the project, in terms of money, time, quality, and so forth, then I will do so.

If there is action that can be taken, but would take me beyond my contingency, then I need to ask the Executive for guidance. Remember, any changes to the project outside of contingency need to be agreed – it is entirely possible they could take the project from a worthwhile use of company resources, to a waste of them.

Finally, I need to make sure that I update my log of issues with action taken, and any other information on the issue.

I’ve been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

Last week, I suggested a first project management concept, that the primary aim of every project is to benefit the business. I also said that projects are about change – bringing change into a business.

And this leads us to a second project management concept: Project management is about making the project environment as stable as possible. What is possible varies.

Let’s explore what I mean by this. We’ve already seen that a business needs to embrace some change to make sure it continues to compete in its market, to stay relevant to its customers. But businesses in general try to be stable – to provide certainty to shareholders and staff.

These two competing demands come to a head in projects. Projects bring change into the business, which means they could be seen as threats to the business stability. Uncontrolled change has a name – chaos. So change can only be brought into a business in a controlled manner.

And this is what project management is about. Projects are about change, so the management of that change is an attempt to control it. It is an attempt to provide a stable environment within which change can happen. That stable environment protects the business from uncontrolled change, while providing a space for change to occur.

But, of course, how stable the environment can be depends on the specifics of the project. For example, a project to build a new office building needs a very stable environment indeed – an attempt to change the design after work has begun on construction is likely to be impossible, or exceedingly costly.

Alternatively, software projects can cope with a much less stable environment – yes, work may need to be done to ensure earlier completed sections are adapted to the new design, but this is much more possible, and cheaper, than with a physical product.

We can see, then that “as stable as possible” can vary widely. This is a natural consequence of the particular change being brought about through a project.

This gives us, then, our second project management concept: Project management is about making the project environment as stable as possible. What is possible varies.

What do you think? Do your project environments push for more stability, or more change? Let me know!

We’ve already talked about the idea of risk management as part of the project. Obviously the first requirement for the rest of the risk management process is actually to have identified the risks!

Identifying risks can be a tricky business. But there are a few things you can do to make it more successful. The first thing we need to do is look at what we are actually trying to find. We are trying to figure out what things could happen that will effect the project in a bad way.

So what would be a bad effect on the project? Well, traditionally we are trying to protect three main areas in a project: time – how long it takes us to complete the project; cost – how much it costs us, in terms of money and resources; and scope – what the final output will actually do. In addition, the quality of the final output can be effected.

By keeping these four areas in mind, we can start to identify what some of the risks could be:

1. What could happen that will affect how much time we have?
   • Could the launch date be moved forward?
   • Could poor weather conditions delay external work?
2. What could happen that will affect how much money we have, or can spend?
   • Could the project budget be cut in a lean time?
   • Could our suppliers put their prices up significantly?
3. What could happen that will affect the scope of the project?
   • Could a competitor put out a product which covers something we don’t, meaning we need to expand scope?
   • Could part of the project be more complicated than expected?
4. What could happen that will affect the quality of the output?
   • Could a component from a supplier not meet our requirements?
   • Could we run out of time for removing bugs from code?

By identifying the things that could happen that will affect us, we can not only identify them as risks, but also identify the drivers behind them – what will cause these risks to occur? In that way, we can start to make sure we head the risks off early, and hopefully make sure they don’t occur.

I’ve been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

Today I am going to get back to the very basics. Why do we do projects? What are they for?

I think this one is simple, but far too often forgotten: The primary aim of every project is to benefit the business.

To begin with, let’s look at the traditional view of business as usual. A company has a particular process it goes through to create its product, to produce as many of it as the company can.

One of the things we can say about this situation is that it is steady-state – the company can continue going through the same process to build ever more of its product. But, of course, the environment that the business operates in is going to change. And that means the company needs to adapt.

This is where projects come in. A project is about change. An individual project in this case could be about improving manufacturing methods, developing a new product to make, finding new markets, and so on. While the details of the project may change, all of them are change, about bringing change into the business.

But why would we want to do this? Why bring change into the business? Well, as I have already suggested, a business cannot stay the same while the environment it is in changes. New competitors may arise, economic conditions may alter, suppliers may go out of business.

A company that doesn’t react to these changing conditions, that doesn’t bring change into itself, will fall behind. It will suffer because other companies *are* reacting to the changing environment. These companies will take their market share, and eventually drive the first company out of business.

This means that we need to find a way to help the business. We need to deliver a project that benefits the business.

Now, of course, that benefit can make different forms. In general, the output of the project will directly either make, or save, the company some money. For example, the project may develop a new product to be sold, or improve manufacturing processes to reduce costs.

But this is only a generalisation – it may be the project itself only touches on the financial side indirectly. For example, a project may improve brand awareness in the marketplace. While this improved awareness will lead to increased sales, the project itself doesn’t deliver them.

So that’s why we do projects – we bring change into the business, and by doing that, or at least doing it successfully, we benefit the business. And that is my first project management concept: The primary aim of every project is to benefit the business.

What do you think? Do your projects have a different primary aim? Let me know!

So, I’ve already talked a little about how to ensure quality in what you are producing. But let’s take a look at it in a little more detail, to get a better understanding.

As we know, we need to make sure we have criteria that describe what the quality of the final output should be. These criteria need to be agreed beforehand between those making the output, and those who will be using the output.

But quality isn’t just something to be tacked on to the end of the project, polishing the final output until it comes up to scratch. Quality needs to play a part throughout the project. Each task that forms a part of the project should have appropriate quality constraints as part of it.

But what is an appropriate quality constraint? Well, the most obvious constraint is that the output of the task should actually be what the task was supposed to produce! It should meet the criteria that have decided before the task started.

Now, these criteria will not have been decided at the very top level. No, they should instead have flowed from the quality criteria that were set at the top, for the output of the project as a whole. But for the individual tasks, criteria should be set either as part of the scheduling meetings, or when the tasks are being divided up among the team.

And, of course, we need to have decided who gets to assess whether the output of the task meets the quality criteria. Usually it is better to have someone who didn’t do the work to assess the quality. This isn’t because the person who did the work is going to deliberately conceal flaws (hopefully…) but simply because they are likely to have been too close to the work for too long to be objective about it. Fresh eyes see more clearly.

Finally, don’t think you can get away form this scrutiny as a project manager. Don’t forget that you have many tasks that need to take place in the project too – monitoring, production of reports, etc. All of these are an output of a task – and so they should also be subject to a check on their quality!

At the beginning of the project, we should have identified a project assurance role, and someone to fill it. This role should be examining the project management outputs, and providing feedback and info to you on improving them, as well as providing the independent eye of the Executive in checking progress of the project.

By checking quality throughout the project, you make sure that by the end, we don’t have to suddenly tack on a few more weeks to get the final output to the quality it needs to be. It should just flow naturally from the high quality of the tasks done to get to the end.

One of the favourite sayings of my father is “Wisdom is not in not making mistakes, but in not making the same mistake twice”. This is an important lesson for all of us as project managers. Learning from our mistakes helps us to become better project managers – experience is always a good teacher.

But what we should all be trying to do is make sure we are not the only ones to learn from our mistakes. Making sure others in our organisation, or even our profession, get the benefit of our experience is an important part of our professional lives.

So how do we go about this? Well, first of all, we need to recognise when we have made mistakes, when we have not taken the best action in a given situation. This needs a certain amount of honesty, and to be done well, it needs time to really consider the project as a whole.

The best way of doing this is to analyse the project when it comes to an end. Hopefully, the project will come to an end successfully, with the end result we wanted delivered. But it may be that the project has been stopped early, for whatever reason. Regardless, at this point we need to evaluate a number of things:

• Exactly how successful was the project really?
• What actions did we take that helped?
• What actions did we take that didn’t?
• What problems occurred?
• How did we deal with them?
• Were there things we could have done better?
• Were there things we didn’t do that could have helped?

As you can see, there is a lot of ground to cover. You will also note that a lot of this involves honestly looking at your own work. Now, this can be tough, especially when looking at places where we messed up. But it is only by examining our mistakes that we can learn from them.

However, to help us out in this area, it is always useful to have help in doing this analysis. Your Executive is a prime example to examine your work, but don’t neglect your project team members. Your team will have a different perspective than your Executive, and as they are closer to the nitty gritty work of the project, may have valuable insights into areas that went wrong.

But I don’t want you to go overboard on only focusing on the mistakes. It is equally important to learn from the successes, so that these can be replicated in the future.

All of this analysis should be formally presented as a report, an evaluation of the project as a whole, a set of lessons to be learned. This report should be the final part of your project, where you look back at the work that was done. It can form a valuable tool for future project managers working on a similar project – your experiences can inform their work.

This means that hopefully not only won’t you make the same mistakes again, nor will anyone else in your organisation!

Oh, and that saying my father likes? I don’t know who said it first, because a similar message is attributed to numerous people. Which kind of demonstrates the benefits of spreading good messages too – lots of people can learn from it!

1. The Social Media Project Manager – Blogs
2. The Social Media Project Manager – Twitter
3. The Social Media Project Manager – FriendFeed
4. The Social Media Project Manager – More Twittering
5. The Social Media Project Manager – Social networking
6. The Social Media Project Manager – An Example
7. The Social Media Project Manager – Wikis
8. The Social Media Project Manager – Blogging Community
9. Edit: I have also put together a slideshow for this series, The Social Media Project Manager – The Movie! Hope you like it!

Over the past few weeks, I have been highlighting some of the tools that can loosely be described as social media. The tools can be of use to a project manager in a variety of ways. Some of them can be directly used to help manage your projects, some of them to help you learn and develop, and some of them can be used for both.

As the series has gone on, my use of some of these technologies has also increased, as I have started to find them more and more useful. Of particular note to me are Twitter and FriendFeed, both of which I have found exceptionally useful. These two tools have helped me become more involved in the online project management community, both by seeing what others are doing, and by trying to contribute!

My resolutions moving forward are to continue to play a part in the project management community, most especially through Twitter and the Project Management Guide FriendFeed Room. I will also continue to search for new ways and new tools of social media to use in project management.

What about you? Which of the tools have you found most useful, or most interesting? What are you going to do to use social media in project management? Or are you going to steer well clear? Let me know your views!