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!

Sometimes things like this happen. I had planned to spend some time writing a post that has been simmering in the back of my mind for a while now. But wouldn’t you just know it, an unexpected meeting has come up, and suddenly I’m only got 15 minutes. But I need to get a blog post done today, now.

Which means I need a new idea to write about, something I can get done quickly. But I was severely lacking in inspiration, or so I thought. Turns out, when the deadline looms, words start to flow.

And haven’t we all experienced that in project management? How many times have you been ambushed by senior management with surprise meetings, attendance compulsory, which knock out your personal schedule of work? How many times have you had a deadline suddenly imposed from outside, and suddenly you have to produce something that hadn’t been asked for, with practically no notice?

I don’t know about you, but I’ve been in that position before. I’m almost convinced there is a type of manager who delights in springing deadlines on his staff, like a teacher handing out pop quizzes to a class.

Hopefully, most of the time these deadlines will just be demands for information on the project, which you should be able to meet fairly easily thanks to the monitoring you are doing. But sometimes you get a real doozy of a question, something that means you have to produce something new.

And this is when all our techniques for managing work, and tasks, and time, are blown out of the water by someone above us. So what do you do?

Well, I tend to embrace the power of the deadline. Like I was saying about this post, inspiration didn’t seem to be coming, but the deadline looming kick-started my brain. And this can happen with your work as well – knowing you have to deliver, and fast, can reduce the mental delays that we all inflict on ourselves in some way.

Not that this is an ideal situation – much as I’d like to kid myself, this post is unlikely to be of a quality I’m happy with. But sometimes, we need to make sure we deliver something with some value quickly, rather than massive value late. So embrace the adrenaline surge the deadline provides, and get working!

And, after the fuss and the commotion of an imminent deadline has died down, take your manager aside and point out to him that, really, you need more notice of these sort of requests! It’s all very well responding in an emergency, but your time is part of the project resources too, and that means you need to guard it as jealously as you do the time of your project team.

I hope this has delivered some value, because I really have to go now – don’t worry, I’ll have a word with myself to make sure this sort of deadline doesn’t crop up again…

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!

Jurgen Appelo wrote a post a couple of days ago, Your Software Project Has No Goal. His argument was summed up in the first sentence:

Human beings, organizations and software projects share one important thing: they have no intrinsic goals.

Um… no. That’s wrong. And the reason why it’s wrong is in the very next sentence:

The goal of something that emerges from interacting parts is not determined by the goals of those parts.

The key point here is Jurgen is talking about something that emerges from interacting parts, an emergent phenomenon. But an organisation or a project isn’t an emergent phenomenon – they are created, and created with a purpose, a goal.

There are plenty of emergent phenomena all around – the flocking of birds, the building of termite mounds, convection cells in heated fluids, and so on. What all these examples have in common is that they display behaviour at the macro level – that of the flock, colony, or convection cell – which emerges from much simpler behaviour at the micro level – the individual birds, termites, or convection particle.

So, for example, in flocking a bird may only be obeying three simple rules – keep in touch with the flock, travel in the same average direction, but don’t get too close to any individuals. From these three simple rules, we start to get the typical complex flocking behaviour we all recognise, despite none of the individuals trying to behave in that manner.

In other words, the flock doesn’t have an intrinsic goal – it only happens because of interactions between participants having an emergent effect, not because they decide to form and behave as a flock.

Perhaps the strangest example of an emergent phenomenon is intelligence. Billions of neurons are connecting to each other, each individual cell following simple chemical prompts. But out of all of this, we get thought, memory – consciousness.

But the important thing to remember about all of these phenomena is that they emerged not because they were what the individual participants were aiming for, but as an unexpected outcome of it. You can readily see, however, where this breaks down for organisations and for projects.

You see, organisations, at least business organisations, don’t typically start because there happened to be a few people hanging around. They don’t emerge because separate individuals are trying to have a job.

No, organisations start because some individual, or group of individuals, decide to begin an organisation. And this is the crucial difference – an organisation is the intended outcome. To this end, a group of people are employed to be part of that organisation. An organisation is not an emergent phenomenon, it is an intended one.

And because there is a conscious effort to make an organisation, because it is an intended outcome, there is a purpose behind it. The decision to start an organisation is made because it is thought to be the best way to achieve what the creator is after. An organisation starts with a goal, otherwise it wouldn’t start at all.

Sure, once the organisation exists the interactions of the people in it may lead to an unexpected culture. There may indeed be emergent phenomena within the organisation caused by the interactions of the individuals inside it. But that doesn’t mean the organisation has no goal, only that the individuals in it have many goals, some helpful to the organisation, some not.

But because the organisation is a conscious creation, the creators of it harness these interactions, or stop them. For a business as a form of organisation, the simplest generalisation of a goal is to make money for the creators, or the owners. So those efforts of the individuals that help this goal are rewarded – by decree of those on high. Those efforts which damage this goal are punished – by decree of those on high.

And this goal, to make money, is an intrinsic one – it is the very reason the business exists. The reason an organisation can have this intrinsic goal is because it is created – it is not the product of interacting elements.

The same argument follows for projects. Projects don’t (or at the very least, really shouldn’t) start because there are some developers sitting around twiddling their thumbs, time on their hands, nothing to do. No, a project starts because some conscious agency, a creator, decrees that there is a problem to be solved, an aim to be met, a goal to be achieved.

That act of creation means the project starts with an intrinsic goal – again, because a project does not emerge out of the interactions of those within it. It is created, and then people are brought into it.

Of course, the intrinsic goal may be a bad one, but that doesn’t mean it doesn’t have an intrinsic goal. As a starting point, it is probably fair to assume the intrinsic goal of all projects in a business is to make, or save, the business some money. Why? Because then the intrinsic goals of the project and the organisation are aligned – meaning the project is far more likely to have been given the go ahead to begin.

It is the fact that an organisation and a project both have a conscious act of creation, an act with a defined purpose, that means they both have intrinsic goals. Religious arguments aside, there was no conscious decision made to create a race of hairless apes who run around asking questions, which is why humans don’t have intrinsic goals.

Human beings: no intrinsic goals. Organisations: intrinsic goals. And, sorry Jurgen, but yes, your software project does have an intrinsic goal.

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.