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.
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:
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!
Yesterday was the PMXPO 2009, an online project management conference. It was a fantastic event, and I want to thank all the people at Gantthead for putting it together. I really enjoyed the presentations, and learnt a lot.
The presentations that were given were:
Now, as I said, the conference was yesterday… but thanks to the wonders of virtual conferences, you can still go and see the presentations! Just pop along to the PMXPO 2009 site and register – and get watching.
(Oh, and for those of you who are PMPs, you can also earn PDUs from the presentations – what more reason do you need to check it out?)
Something big is going to happen with PRINCE2 very soon now. The old version is undergoing an update, or as those responsible call it, a “radical evolution”. And it looks like this could be very interesting.
PRINCE2 is often attacked for being overly bureaucratic, or too complicated, or needing too much documentation. This update, which will be release on 16th June 2009, is tackling these complaints head on.
The biggest change has to be the introduction of a set of seven principles for PRINCE2:
This is an important development for PRINCE2. Not because the principles are new – they’re not. They’re the same principles that good PRINCE2 Practitioners have been using all along. But this is the first time that they have been set down and expressed as part of the methodology.
There is more information in Andy Murray’s presentation on the PRINCE2 update. Andy is the Lead Author for the update, and you can read more on the PRINCE2: 2009 Author Blog.
We all know that the purpose of a project is to deliver some sort of benefit to the business. For many projects, the real benefit is that the end result is being sold. But what about projects that are purely internal? What about projects that are trying to change the business?
I’ve run across a few of these in my time. One thing they all seem to have in common is that they are driven from the top – they are designed to deliver a benefit to the senior management. That’s not surprising – senior management are the only ones who can commit to spending money on them!
But that also causes problems for a project manager. When the project is being put together, it’s always a good idea to make sure that there are also benefits to the people who are going to be affected by the changes. Without their support, the project is very unlikely to be successful.
Let’s look at an example. Quite a while ago, I was working at a fairly large and bureaucratic public body. Their whole reason for existing was to pay for and support projects to support and grow the local economy – business support, infrastructure building, that sort of thing.
Naturally, this meant they needed a lot of information. This information was going to be particularly useful to the senior management who had to report upwards to government. But getting this information could be difficult. So naturally, a knowledge management solution was proposed.
Now, this solution was going to use simple techniques – tagging of all documents with keywords, imposing a defined directory structure, and so on. For the senior management, the promised benefits were great: they would be able to drill down into any area, and all the information would naturally flow into a dashboard view.
But the benefits for the other users were minimal, at best. They already had developed their own directory structures. They knew where all the information was. The problem senior management had simply wasn’t a problem for them.
But senior management’s solution, well, that became a huge problem for the staff! Suddenly they had to start adding keywords before they could save their files, they had to try and fit their documents into a structure they couldn’t control, and so on. There was now a new barrier to them doing their work, without any benefit to them!
When the poor soul put in charge of this project ran the concept past me, I was sceptical. It seemed fairly clear the project was going to be horrendously unpopular, and difficult to get finished due to the resistance it would encounter. But my colleague didn’t want to say anything to senior management – he believed that the staff could be made to use the system through coercion, rather than choice.
Maybe he’s right – but you’re not going to get the real benefits out of a system people don’t want to use. Keywords would be selected poorly, missing out a number of useful ones. The directory structure would get filled with files in the wrong places. The expected benefits wouldn’t be delivered.
Not surprisingly, the project hit difficulties almost as soon as it was started, with resistance from all sides, and pressure from above to get it implemented quickly. It dragged on for far too long, before finally it was scaled back, and the business actually talked to staff about what they wanted to get out of the system.
Always remember that to implement an internal change project, you need to make sure you deliver benefit to everyone affected, if possible. If it isn’t possible, minimise the pain as much as it can be, and realise it is going to cause you problems and delay.
What do you think? What barriers do you run across when implementing change? How do you get the buy-in of the various groups? Let me know!
So, the latest Standish Report is out. The figures in it are depressingly familiar. More projects are failing. Only about a third of projects are succeeding – on time, on budget, on scope.
Now, there are a lot of reasons to be dubious about the CHAOS report statistics. The categories are fairly vague, and don’t appear to look in any depth about whether (for example) a project being cancelled was a good project management decision or not. The methodology they have chosen for the study is unclear. So as an absolute measure, they’re not up to much.
But because the report has been produced for a number of years now, with, presumably, the same methodology, we can get some value from using them as a relative measure – are things getting worse, or are they getting better?
Well, in fact, the figures for project success seem to be holding roughly level over the past few years. There has been an improvement from the original report back in 1994, which suggested a success rate of 16%, but we seem to have been hovering around the 30% mark for many years now.
And this is worrying, considering the amount of effort that has gone into developing better and stronger project management methodologies, techniques, tools and so forth. Taken at face value, the CHAOS report would suggest that we needn’t have bothered!
That suggests a couple of possibilities. The first one is that as a group, project managers have simply got it wrong. Perhaps the tools we are using to manage projects, the methodologies and techniques, simply have no effect. All we have done is made our own lives harder, but at least we haven’t damaged the projects we work on.
I’m not really inclined to believe this possibility. (Though, of course, as a project manager, I have a vested interest in saying a methodology is needed…) The reason I’m not convinced is that the methodologies have been developed from the experiences of many project managers. They are finding new ideas that work for them in their projects – they are seeing an improvement in the project management process by using these techniques.
The other possibility is the one I am interested in. It’s loosely based on the Red Queen Hypothesis. What if project management is getting better, but projects are also getting more complicated? What if we’re running just to keep still?
Think about the IT projects you’ve been involved with over the years. Have they become more complicated? Have our ideas of what we can achieve become bigger? Do projects now pull in many more aspects of the business than they used to?
I’m not even entirely sure how you would test this idea. (Always a hallmark of a less than perfect hypothesis…) It would require some way of evaluating the complexity of a project against a baseline – a baseline that needs to stay steady as the world changes around it, and as new technologies may make some of the assumptions in the baseline wildly incorrect. Now that would be a study worth doing.
I genuinely don’t know. My personal feeling is that, yes, IT departments are willing to take on more complicated projects these days. But I’m wary of drawing a conclusion from my own, purely anecdotal, experience. Others may have had very different experiences.
But certainly when we think of how much more we can do with IT than we used to be able, of the added complexities of what it can achieve, there is a certain attraction to the Red Queen idea. But maybe it’s just wishful thinking and self-justification on the part of a project manager…
What do you think? Are we getting better? Are projects getting more complicated? Or have we just overloaded ourselves with methodologies we should dump? Let me know!
