On Wednesday, I told you all how wonderful risk is. Yesterday, I talked about the two different types of risk a project can face, and why a business should be happy to embrace one of them. But should project managers be happy about this type of risk?

Well… it depends. As I said yesterday, the competency type of risk, that involved with making sure you and others have done their job, should be ruthlessly fought. But the other type of risk, the business risk that any project will face, needs to be balanced against the possible rewards.

For a business, this is simple, even if it isn’t easy. You look at the likely rewards if the project is successful, the cost of doing the project, and the chance of the project being successful or, in other words, the riskiness of it. Then, you use a simple calculation to get the expected value – multiply the likely rewards by the probability of success, and if the answer is greater than the cost of the project, go out and do it!

That’s all well and good for the overall business, but what about you, one project manager inside it? This is where it becomes more complicated. And it becomes more complicated because people are much more complex than a business.

As a project manager, you are naturally going to want your project to be a success. But the reasons for wanting the project to be a success are a lot more complicated than the reason a business wants the project to be a success.

A business gets (usually) a clear and obvious financial reward from a successful project. A certain amount of money goes into running the project, and at the end of it, hopefully a larger amount of money comes out as a result. This is pretty much the only concern of the business.

For a project manager, though, it goes beyond that. Yes, you will want to deliver value, and profit, for the business. But you will have other reasons for wanting the project to be a success.

You will want the people on the project to do well in their careers, and a successful project helps that. You will want to do well in your own career! You will have an emotional attachment to the project. There are many reasons why you want the project to be a success.

But there is another side to a project manager’s connection to the project. Yes, we will want it to be a success. But we will also fear it being a failure. And fear of failure can be a very dangerous thing.

We fear having a failed project on our record. We fear a history of failure could hold us back in the future. We fear a loss of prestige. And, worst of all, we fear losing our jobs due to a project failure.

The problem is that we, as people, rather than project managers, have to deal with two risks. There are the project risks, and there are the personal risks. We know how to deal with the project risks, how to evaluate them, mitigate them, remove them, or accept them. But personal risks are a lot more complicated, a lot more difficult for us to deal with.

Let’s face it, no matter how confident we are, the personal costs of a failed project can seem huge. When we fear for our jobs or our future careers if a project fails, is it any wonder we shy away from risky projects? Even if we did the same evaluation as a business, the project manager personally seems to have so much to lose from a failure, and relatively little to gain from a success.

And that makes it rational for us to stay away from risky projects – even though they may be of great benefit to the business!

Now, this is a problem which has to be tackled by the business. After all, they have the most to gain from running riskier projects. So what can be done?

Well, as we’ve seen, the risk versus reward needs to be rebalanced. The project manager fears losing so much, but gains so little from a successful project. This leaves two obvious solutions.

The first one is to greatly increase the possible rewards. Offer huge bonuses, promote a successful project manager, give him or her a share of all the profits.

On the whole, I suspect businesses are unlikely to go this route.

The second one is to greatly reduce the possible losses. Now, this has, I think, more mileage in it. There are simple and inexpensive ways for a business to do this. Here are five examples:

• Don’t just praise success – praise failure. We learn more from failure than success. If the project team has done their job well, but didn’t quite make it, praise them for their efforts.
• Stop saying a project has failed when it hasn’t. If the project team did their job well, but the project still didn’t give the hoped-for result, then praise the project team. The project team can control the output of a project – what is actually produced – but they can’t control the outcome – how that output is received. In other words, if they created the new product that everyone thought the market wanted, but it didn’t sell, they still did their job!
• Stop pointing the finger. Given we know there are risks we can’t control, the business risks that can’t be got rid of, businesses, and the people in them, should stop working so hard to assign blame. Not everything is someone’s fault. Quite often, bad things happen without anyone causing it. Accept it.
• Support project managers. Accept that some things are outside of the control of even the best project managers. If the project has shown areas they are weak in, help them get better. Stop using the result of one complicated, difficult and unique project to predict how the project manager will do in another complicated, difficult and unique project.
• Judge a project manager by project management success, not the project success. Be fair, and only evaluate a project manager based on what is actually in their control.

By taking these and other steps, by working hard to change the culture of the business, they can change the personal risk versus reward calculation for a project manager. Reduce those risks, and get good project managers excited about doing risky projects.

Because risky projects worth doing offer the best reward for businesses, and, in my experience, are a lot more fun to work on for project managers. So, I ask again the question that started all this, I ask it both of project managers and of businesses that run projects – don’t you wish you had riskier projects?

(Image courtesy of afanc. Some rights reserved.)

Yesterday, I told you all how wonderful risk is. But it is fair to say that most of us work very hard to get rid of risk from our projects. Why this difference?

Well, I think it is because there are two broad types of risks in a project. The first type is one that we all should try to reduce. It’s to do with competence, with doing our job well, with checking we are putting the project in the best position to be a success.

The second type of risk is the one I like. It’s to do with the change we are trying to bring about, the effect we are trying to have on the world outside our project. It’s the risks that you can’t get rid of, because they are part of why you are doing the project.

But because as project managers we have to deal with so many risks of the first type, we seem to get stuck in the mindset that risk is bad, that risk must be removed, that we have to play it safe. But trying to play it safe may be the most dangerous thing you can do.

Let’s look at these two types of risk. The first type are risks that we can and should get rid of. If you are creating a new product, of course you’d do market research to find out if there is demand for it. If you are putting in place a new business process, of course you’d talk with users to find out what they want from it.

To put it bluntly, of course you’d do your job. A lot of the risks we can easily get rid of in a project are really around making sure we’ve done our job correctly, and around making sure others in the business have done theirs. So of course we need to be interested in getting rid of these risks.

It’s like climbing Mount Everest. Before you go, you do your research and decide that it’s probably best to pack warm clothes. You may even investigate further and decide a few bottles of oxygen will come in handy. You make the preparations that get rid of the risks that can be got rid of.

But that still leaves the second type of risks. We may know there is a market demand for a new product – but will your product actually be successful? We may know what the users have told us they want from a new process – but will they actually use it?

These are the risks we can’t get rid of. Yes, we can do everything we can to create a product that meets the apparent needs of the marketplace, but we can’t know people will buy it. We can do everything we can to produce a process that is simple and easy to use, but we can’t know users will switch to that from what they already know.

Going back to our Everest metaphor, you can wear cold weather gear, carry oxygen, and make sure all the equipment you could need is available. But at some point you actually have to go out and climb the mountain, facing the dangers of the cold, the thin air, the strong winds, and the avalanches.

In other words, before you set off on your adventure, you make sure you have taken all the sensible precautions – and then you set off to face the danger anyway.

And there’s actually a good reason for that. Setting off to face the danger only makes sense if the rewards for overcoming it are significant. Those rewards, whether they are financial, social, personal, whatever, are the reason for facing the danger – the value of that payoff is weighed against the danger in achieving it.

In the same way, we weigh up the possible rewards of a successful project – be it increased profit, reduced costs, and so on – against what we are risking if the project fails – wasted money and time, lost opportunities, and so on.

So risk is good – at least, the right type of risk is. If there is a high risk project that we can do cheaply, then we definitely should. The concept of expected value (here’s an example of expected value in poker) comes into play here – though the probabilities involved with success and failure of projects tend to be harder to estimate!

For a business running a lot of projects, they can almost treat their projects as a gamble – they will stake a certain amount of ‘value’ (money and time) to try and achieve a larger amount of ‘value’. If the probability stacks up that you are making a profit, then do the project – accept the risk, embrace it.

Now, all of this makes sense if we are a business looking at risk, and trying to find a sensible way to deal with it. But what about just us, as project managers? It’s all very well knowing the second type of risk is different for the business, but is it different for us? Well, it all depends – and that’s what I’ll talk about tomorrow.

(Image courtesy of psd. Some rights reserved.)

Risk is the absolute best thing you can have in your project. Yes, you read that right. I’m a project manager who craves risk, who wants risky projects.

I feel like I should start a support group: “Hi, my name is Trevor. I am a project manager and I like risks”. But my group wouldn’t be trying to stop anyone taking risks, it would be encouraging it.

Think about it. A project is a new venture, a new risk. Or to use another word from the same root, a project is a new adventure. Now, doesn’t that sound better? Doesn’t that sound a bit more, well, exciting?

“A new adventure” brings to mind much more interesting ideas and concepts than “a new project”. We think of excitement, of courage, of winning through against the odds. In other words, we think of the upsides of overcoming danger, the positive aspects of risk.

For many project managers, though, “a new project” immediately brings to mind thoughts of caution, of danger, of failure. We think of the negative aspects of risk. And not unnaturally, we start to think of how to get rid of the risk from the venture, to ‘de-risk’ the project.

But consider this: Any project has to include risk. Yes, it has to. A project is about change, about creating something new, or doing something differently. And any change has a risk associated with it – we simply can’t know exactly what will happen.

But this isn’t a bad thing! It is thought that the word ‘risk’ derived from an Arabic word ‘rizk’, meaning ‘to seek prosperity’. Similar words were used in the Middle Ages specifically to do with the dangers involved in sea trade, in sending goods you had paid for out onto an unsafe sea, in the hope of selling them for a profit elsewhere.

If you think about it, we often use risk to mean the same thing today – we risk our money by buying shares, or by trading in commodities, or even by starting a project! We are putting our money in harm’s way, risking it being wasted or lost, in the hope that we will in fact get a bigger return.

Risk is good. Without an element of risk, we won’t be able to achieve success. Without risk, we don’t have a project. Without risk, we’re just doing the same old thing again – we’re doing business as usual management, not project management!

And usually, the bigger the risk, the bigger the potential reward. A big reward sounds great! So why do we all, (project managers, I mean) seem to avoid risk wherever we can? Well, that’s what I’m going to talk about tomorrow. See you then!

(Image courtesy of szlea. Some rights reserved.)

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.

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.
• Project management needs both awareness and control of the project. Control is impossible without awareness.
• The project manager can control time taken, money spent, and scope fulfilled – but only within set limits.
• The project team is a project’s most important resource. Guard them well, to allow them to get one with their tasks.
• The project manager doesn’t do the project work. The project manager does the project managing.
• Only work a project team member is doing on something assigned by the project manager is project work.

Today I want to look at the knowledge that all project managers need about the work on their project. The project management concept I will be looking at today is: Project managers need to know what has been done, what is being done, and what needs to be done.

We need to have knowledge of what has already been done. It is important for us to know the path we took to get to where we are now, to understand the decisions we took, to remember the obstacles we had to overcome. In this way, we can learn from our project experience, and make our future path smoother.

We’ve already seen that we need a good awareness of what is happening in the project at present. This awareness, this knowledge of what is happening right now is means we become aware of problems as soon as possible, to make sure we can solve them as quickly as possible.

We also need to have knowledge of where we plan to go next. It is important for us to have a clear idea of where we are going, to understand the challenges that we will face, to accept that unforeseen problems will arise, and to plan to deal with surprises. To make sure these unexpected events don’t derail the project, we have to have an understanding of our final objective.

By having knowledge of these three areas – the past, present, and future – we can improve our project management. We can do this by drawing on our experiences from the past to help us overcome obstacles we face in the present, and plot a course around foreseeable problems in the future.

And that leads us to today’s project management concept: Project managers need to know what has been done, what is being done, and what needs to be done.

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

Following on from my post last week, Managing versus Directing: PRINCE2 2009, here is a video in which the Lead Author, Andy Murray, takes us through the two new publications that will be available. The video is from Best Management Practice.

Communication is vital in project management. In fact, I’d say good communication skills are one of the most important qualities a project manager can possess. But is a project manager getting involved in the internal communication of the project team actually providing value?

As a quick thought experiment, let’s imagine a team of five members. In a self-organising team, it may be that each member has a discussion with every other member to let them know where they are up to, what they are working on, etc. This communication, in one direction (i.e. person A telling person B their situation) takes an amount of time I’ll call t.

Now, the communication cannot be one way – person B also needs to tell person A what they are up to. So they also take time t to pass that information on. So the total time for the update conversation is 2t. But the total work time is 4t – i.e. 2t for each participant.

I have shown this situation in the 5 person team in the diagram. In this situation, each person talks to every other person. There are 10 conversations, each taking a time of 2t. This means, with two people in each conversation, the total work time used is 40t.

Now let’s look at the situation when we add a project manager. In this case, I have assumed each team member tells the project manager where they are up to. The project manager then evaluates the information, and feeds back to every team member. The two way conversation thus still exists, though the two ways may happen at different times. In this model, there are 5 conversations, each of which take time 2t, giving a total time of 10t, or a total work time of 20t.

In other words, adding a project manager reduces the time the team spends in sharing information by half – in this particular case.

Of course, there are other possibilities. It may be the self-organising team shares information through a meeting, rather than separate conversations. This would dramatically reduce the total time. In this model, person A tells all the other members of the team what they are doing at the same time. Then person B does so, and so on.

This reduces the total time taken to just 5t, but the total work time is only reduced to 25t – it only takes person A time t to update the other 4, but each of the 5 has to be there, a total of 5t work time. This is repeated for the other 4 people.

In a team with a manager the total work time would be higher – purely because the project manager has to sit in the meeting too. If, however, the project manager receives updates from the team members individually (for a total work time of 10t) and then feeds back to the entire team (for a total work time of 6t) then we have a total work time of 16t – again less than in the self-organising team.

We can easily expand this up to teams with 10 members. In this case, team members holding individual conversations gives us a total work time used in communication of 180t, a team holding a meeting gives a total work time of 100t, while a team using a manager and meetings takes a total work time of 31t!

At this point it all looks cut and dried – self-organising teams, even if they use meetings, spend far more time in communication than a managed team.

Of course, that’s only true when you have been as grossly unfair with the figures as I have. (Using pseudo-scientific methods and information to draw unfounded conclusions is fun!)

The most obvious way I have been unfair is assuming the project manager can condense down everything all the team members need to know massively. In the model where the manager has a conversation with each team member, I have decided the information which the other team members took 4t to pass to him can somehow be condensed down to only take t for him to pass on! This seems rather unlikely…

So no, I’m not saying these figures are going to be accurate. But they do illustrate some important ideas.

1. Time taken to communicate amongst a team rises dramatically with team size.
2. The most effective way to reduce this is to hold meetings, so team members don’t have to repeat themselves with each other member.
3. Project managers can aid communication if they act as a central collation point.
4. But the best improvement in communication comes if the project manager condenses or filters the information.

In other words, you need to be more than good at talking. A project manager needs to understand the project well enough to know who needs to know which pieces of information, and just as importantly, which pieces of information are of no use to other members. You need to act as a filter, to make sure you’re not wasting the time of your team members.

Communication isn’t about how much you say to everyone, it’s about saying the right things to the right people.

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.

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.
• Project management needs both awareness and control of the project. Control is impossible without awareness.
• The project manager can control time taken, money spent, and scope fulfilled – but only within set limits.
• The project team is a project’s most important resource. Guard them well, to allow them to get one with their tasks.
• The project manager doesn’t do the project work. The project manager does the project managing.

Today, I want to look at one of the fundamental ways we maintain control on a project. As we’ve already seen, control is impossible without awareness. So we’ll also look at one of the ways we gain awareness in the project. The concept I am looking at today is: Only work a project team member is doing on something assigned by the project manager is project work.

We know we need both awareness and control. One of the clearest and simplest way of gaining awareness is for the project manager to assign all work that takes place on the project. Indeed, this is one of the purposes of the project manager role – to allocate the work sensibly, without doing it himself.

But by assigning work, the project manager is also taking control. By doing this, he or she is demonstrating to the project team that only work assigned like this is work on the project. Thus, assigning work gives a project manager both awareness and control.

And that gives us our project management concept: Only work a project team member is doing on something assigned by the project manager is project work.

Well, we’re heading into a long weekend over here in the UK, where hopefully we’ll all get to have some down time, a chance to let our brains catch up with our bodies for a bit.

All of us are guilty at one time or another of letting ourselves get distracted from the important parts of our job. As an example, take a look at this experiment by Gantthead’s Dave Garrett. (Yeah, I cheated and answered twice – what can I say? I must be indecisive…)

None of those answers are wrong, or unimportant – but how often do we forget about them?

For example, right now, there is a big buzz around using social media in project management. This is something I happen to think will be big in the future – I’ve written about the Social Media Project Manager before, and there’s even The Social Media Project Manager Slideshow. But, and it’s a big but, there are still lots of challenges in the way.

And I think one of the challenges is that some of us, and I include myself in this, get very excited by the technology, and focus on that, and forget about the real strength of social media – that being the social part. The people part.

As the Project Shrink says, projects are about humans. And he’s also done some thinking about what problems in project management social media can solve which is well worth a look.

But back to my more general point – we all need to take some time out every now and then to make sure we are still able to spot the important things. So, over this weekend, relax, take some time, re-connect with the important people in your life.

And, yes, have a quick think about what is important in your current project, and what isn’t. Then you know what you need to focus on.

Have a great weekend.

Some projects are done entirely in-house. The business has all the tools and people it needs to get the final result that they want. Often, though, a project will need to bring in outside help – such as buying in equipment.

I’ve worked on some projects which have had major procurements as part of them. I don’t want to talk about the process of that procurement – that’s what procurement departments are for! But I do want to talk about how to handle your supplier once you have decided who it is.

With your internal project team, it is quite likely you won’t have line management responsibility for them. This is what makes your people skills so important in project management – you need to inspire and encourage without having the usual tools a manager does to back it up.

However, with an external supplier, you quite often have a lot of power over them. After all, the whole reason they are there (as far as they are concerned) is to get their invoice paid. If you control the money, you can control them.

But I really wouldn’t recommend this adversarial kind of mindset. Making it all about Us and Them isn’t going to help the project at all. That’s not to say there isn’t a time for that mindset – but that time is in the procurement process, when you are making sure you get the best value for money you can.

When I am bringing a supplier into the project, I really want to make them feel a part of the team. Firstly because they really are part of the team – they are supplying something you need to make the project successful, just like every other team member.

But more cynically, it’s also much easier to get the supplier to go the extra mile if they feel included in the team, if they have some emotional investment in making the project a success, if it is about more than just the money. I’ve had suppliers really push hard to solve problems for me – in one case even getting into trouble with his boss to manage it!

Finally, it just makes for a better working environment. Being inclusive makes the project more fun for everyone to work on, and a happy project team is often the successful project team.

What about you? How do you handle your suppliers? What tips and techniques have you used to get them to go the extra mile? Let me know!

As I mentioned last week, the PRINCE2 project management methodology is currently undergoing a ‘refresh’ to make sure it fits the requirements of the marketplace. The new version, PRINCE2 2009, will be released on 16th June.

One of the major changes has been to slim down the PRINCE2 manual… by splitting it into two. The new version will have two different volumes, Managing Projects Using PRINCE2 and Directing Projects Using PRINCE2.

As you will have guessed, the two volumes are aimed at different users. Those of us who are project managers will be interested in the Managing manual, while senior managers and executives who will be involved at the project board level will be interested in the Directing manual.

Now, in a way I can see the sense of this split. The current PRINCE2 manual does talk about the various responsibilities and duties that project board members need to be aware of, but much of this information is buried amongst the nitty gritty of applying the methodology as a project manager. I can certainly understand that senior staff simply aren’t going to plough through a manual like that.

Indeed, I still think one of the most important things I do as a project manager is to sit down with senior management involved with the project and explain exactly how they fit into the project world – including how they need to hold me to account!

So I can see this splitting of the manual going one of two ways. It is possible that the Directing manual will start to be seen as vital reading for executives. Because they are involved in projects, they will work to make sure they understand their responsibilities, duties, and powers, and we as project managers will gain the benefit of informed and aware executives.

Or, of course, it could be that executives won’t pay a blind bit of notice to the Directing manual – without any qualification (yet) based on it, they may just not waste their precious time reading a rather dry text. Which would leave us as project managers buying both manuals, just so that we can again sit down with our project board and brief them on what they need to do in the project…

Maybe it’s the incorrigible cynic in me, but I rather suspect the second scenario is more likely. But at least we’ll know exactly where to find the information for our briefings…

What do you think? Do you think I’m being too cynical? Can you see other advantages to this split? Let me know!