I think everyone by now knows how I feel about meetings. Certainly they can be very painful to sit through when they are unnecessary, and I think most of us need to cut down on how many we hold.

But one of the biggest issues I have with meetings is actually just to do with organising them. Because I go into a lot of different businesses, I see a lot of methods for arranging meetings. If I’m lucky, they include something like Outlook, and people in the business keep their calendars up to date. If I’m not, then I can look forward to long email conversations trying to arrange a date.

Naturally, this gets harder and harder as the number of people involved increases. Add in people external to the business, and then even the Outlook calendar can’t help you. I can’t even begin to calculate the hours and hours I’ve wasted trying to arrange simple meetings…

Happily, I’ve come across something which gets rid of most of the pain. Doodle is a great service that takes the pain out of scheduling meetings.

It works by letting you give a choice of days and times when you are able to have the meeting. Then it creates a poll, which you can either email as a link to all participants yourself, or even just enter their email addresses and allow Doodle to do that. Each participant is then able to go and select which times they can make.

When everyone has chosen, you get an email telling you, and can go and look what time is best – Doodle will tell you which is the most popular time. Then you can email everyone to confirm the specific time.

No more email tennis, no more phonecalls trying to track down a time everyone can do. Just a nice, simple interface to solve this annoying problem!

Even better, Doodle can interface with very many calendar applications, and if you can’t do it automatically, will even email you a little file which will add the meeting into your calendar.

Doodle is free to use, though it will show you ads. There are also ‘premium’ accounts that have various features, which are well worth considering. The “Solo” version is only €22 / $29, and, frankly, there have been times when I’d gladly have paid that just to get one meeting sorted out…

If you’ve ever felt the frustration of trying to get just a few people to agree on a time and date, check out Doodle. It will make life so much simpler!

There’s a post over at PM Student by Dr Paul Giammalvo comparing project management certifications. I have some more to say about this article later, but I just wanted to put out a quick post about how the PRINCE2 qualifications score in this.

Full disclosure: I hold a PRINCE2 Practitioner qualification.

The PRINCE2 Practitioner qualification scores a lowly 78. (Click through to the article for information on how the scores were assigned.) Compare that to PMI’s PMP qualification which scores 9624. That’s quite a difference. The main reason for the difference is the lack of any pre-qualification training, education or experience requirements to take the PRINCE2 exams.

At first sight, it would look like PRINCE2 Practitioner is an appalling qualification to get, practically worthless. But I think that would be completely wrong.

The problem is that the author is comparing apples with oranges. It’s fairly simple – these are quotes taken from the relevant webpages for each qualification:

“Globally recognized and demanded, the PMP® demonstrates that you have the experience, education and competency to successfully lead and direct projects.”

– PMI PMP Credential

“The Practitioner examination assesses whether a candidate could apply PRINCE2 to running and managing a non-complex project within an environment supporting PRINCE2.”

– APMG-International PRINCE2 Certification leaflet

Put simply, the PMP qualification aims to say “We certify that this person is a competent project manager”. The PRINCE2 Practitioner qualification aims to say “We certify that this project manager can apply PRINCE2”.

It’s an important difference. Certainly when I received PRINCE2 training, it was after I had worked on projects for a number of years. The trainers explicitly started the course by saying the exam does not test your knowledge or skill in project management, but your knowledge of how to apply PRINCE2 to your project management.

PRINCE2 is a methodology, and doesn’t aim to be everything a project manager could ever need to know – as the OGC PRINCE2 website says:

“PRINCE2 does not cover all aspects of project management.  Areas such as leadership and people management skills, detailed coverage of project management tools and techniques are well covered by other existing and proven methods and are therefore excluded from PRINCE2.”

So of course there isn’t a pre-requisite amount of experience or training you must have before taking the PRINCE2 exams – because the PRINCE2 qualification isn’t certifying your competency in those areas, and it doesn’t claim to. It is specifically about whether you are able to apply PRINCE2 to a project.

(In general I’d say there is an assumption you will have a certain amount of project management experience, but certainly it isn’t mandated.)

That’s not to say that PRINCE2 Practitioner hasn’t come to be seen as a proxy for project management expertise – it has, particularly in the UK. But I think that’s mainly because there hasn’t been a ‘professional body’ in the UK attempting to impose a defined set of standards as to what a competent project manager is, whereas there has been a significant amount of work put into improving the PRINCE2 methodology, and popularising its use. Because of its near ubiquity, the market has come to see PRINCE2 as a measurement of project management competency, but the organisations behind it never claimed that for it.

In essence, in many places, being a competent and experienced project manager is correlated with having a PRINCE2 Practitioner qualification, but is not caused by it.

Does this mean we should all rush off and get PMP, and ignore PRINCE2? Well, no. PRINCE2 is, as I’ve said, a methodology. It provides a common set of standards, taxonomy, processes and so forth. It is, in a way, like the protocols used on computer networks – it allows interconnections, and for components, um, people, to be dropped into a new situation and still know the language. There is something akin to a network effect here – the advantages of speaking the same language as everyone else are enormous. It’s something you must be able to do to have any chance of succeeding.

What does that mean? Well, for ‘general’ project management (if there is such a thing), if you’re in a country where PRINCE2 isn’t particularly popular or dominant, especially the US, then yes, plan to gain the PMP qualification eventually. If PRINCE2 is popular in your country, look to gain the Practitioner qualification, but be aware your experience of projects is what will help you get a job, not the qualification.

As I said, I have more I want to talk about regarding this comparison article, and I’ll do that in a later post.

A TED talk by Tom Wujec about the Marshmallow Challenge, where teams of participants attempt to build a tower from spaghetti!

The interesting part for us as project managers comes when we look at who performs well – typically teams who know how to collaborate, and, importantly, iterate their designs based on rapid prototyping. Something for all of us, not just the software project managers, to think about…

You don’t need to be involved in project management for long to come across “scope creep”, which can end up being a major problem. Each extra little suggestion seems like a good idea at the time, and only a tiny bit more work. Soon, though, the extra little things begin to take over the project, and the focus on what was originally planned is lost.

It’s important to spot scope creep starting, and put a stop to it early on. But reading a recent post by Josh Nankivel, called Jenga Project Management Processes, reminded me that there’s another area where project managers need to pay a little more attention, and that’s process creep.

You may not have heard it called that before, but I bet you have come across process creep. You start off with a project with a tight, lean set of processes – just enough to make sure the project is under control. And then someone makes a suggestion…

Suddenly, you have a process for checking in and out project files – even though there’s only one person that does it. Then there’s a process for asking a question about the requirements, and a form to fill in. Then a process for confirming you’ve received a work package, and another one for confirming it has been submitted when you finish.

Eventually you find yourself with a process to go through before a process can be updated or removed or added or you can even go to the bathroom!

Don’t get me wrong, I can see a place for all of these processes – well, almost all. But that place isn’t on most projects. Large, complicated projects need a lot of work to make sure they are kept under control. When you have many people working towards the same goal, perhaps fity, a hundred people, or more, you need to make sure they all know what needs to be done, and how to do it.

But each of these processes is an overhead. In a large project, you have to accept the overhead, because the likely outcome of not having these processes is much more costly, in terms of mistakes, and reworking, and so on, than just having them.

Most projects, though, just aren’t that big. If only one person is updating project files, then they don’t need to check them out – they just need to do it. If someone has a query about the requirements, ask the person that wrote them for clarification, don’t fill in a form requesting that he or she be asked. Make a note of the answer, sure, but don’t make a novel out of it.

Every process has to be looked at in terms both of the benefits it provides, and of the costs it imposes. Generally, the benefits are about avoiding duplicate work, avoiding wrong work, and making sure everyone knows what they need to be doing. But the costs are about lost time, both yours and your project team’s – every time they are filling in a form, or following an unnecessary process, they aren’t getting on with the actual project work.

So keep an eye out for process creep. Remember, a process is just a tool to help you get the project done successfully. If it’s getting in the way of that instead, then you need to fix it, or bin it.

I’ve been thinking for a while now about the difficulties there can be with getting good information about project management when you’re starting out.

Naturally, there are some great resources on the internet. To blow my own trumpet for a moment, my own New to Project Management? page offers some good pointers. Equally, there are a lot of other sites which offer very short introductions to the discipline.

The more I thought about it, though, the more I realised that that is probably not enough for many people. When I first started my career, I was lucky enough to work for an organisation that understood the importance of project management, and had excellent mentors that could help me progress.

But there are many organisations out there that don’t understand this, or don’t have the resources to be able to pay for expensive training courses for their staff. What about prospective project managers in those places? What about the people in those organisations who have already had a project dropped on them, but are beginning to realise they haven’t got the tools to tackle it?

It seems to me that what these people need is a simple guide, not just to what project managers do, but to why they do it. An inexpensive pack of information that not only gives them the tools to tackle project management, but an understanding of when to use them. That understanding is really valuable, and it’s what you need to make all the processes project managers use make sense.

A couple of months ago, I started work on something to hopefully help those people. The more time I’ve spent on it, the more I’ve realised how useful it could be. I’ll be releasing it as my first information product, and I’m pretty excited with how it’s turned out. I hope you will be too.

I’ll be finishing it in the next couple of weeks, and I’ll keep you updated about how you can get your hands on it.

I’ve been looking around at a lot of websites recently that yell about how hard project management is, how difficult it is to figure out. They talk about the complex processes, the confusing techniques, and the baffling methods.

The truth is, though, that project management isn’t difficult. No, really, it isn’t.

At the most basic level, all project management needs is a fairly logical mind, and an ability to keep an eye on what is happening. That’s it. You use the logical mind to figure out what needs to happen, and in what order, and then, once you’ve assigned the work, you keep an eye on it to make sure it does.

Of course, that’s not to say project management can’t be complicated, but that’s a different thing to difficult. The basics above will serve you fine for the smallest projects, but as the projects themselves get more complicated, so do the techniques you need to use to keep on top of them.

Unfortunately, that means a lot of people jump straight into learning a large, cumbersome, and over-the-top project management methodology, complete with its own particular terms and way of approaching a project. While you may need to know these things later, they’re not what you should start with straight away.

The best thing to do is to gain a solid understanding of the foundations of project management, the reasons why project managers do what they do, not just the how. The reasons for doing something will always be more useful to you than just one view of how to do it.

By learning why, you’ll be able to tailor your approach to differing situations. By learning why, you won’t be one of those dreaded project managers that apply one methodology in full, regardless of whether it’s appropriate. By learning why, you’ll be a better project manager.

I’ve previously written in some detail about the processes you need to use or adapt in project management, and the steps you need to take to improve the chances of a successful project. But we mustn’t forget that projects end up affecting people, and we need to make sure they are considered as well.

Four weeks ago, I talked about the three broad types of communication we need to consider in our projects – internal, outgoing, and incoming. Three weeks ago, we had a look at the outgoing communications in the project. Two weeks ago, we looked at the internal communications in a project. Last week, we dealt with communications that are incoming to a project.

Today, I want to look at bringing all of this together in a communications plan.

A communication plan needs some thinking about. The easiest part of the plan to deal with is that of outgoing communications. As we’ve already seen, we need to identify:

• who needs to be kept up to date with what is happening in the project
• how that information should be presented to them
• how often that information should be presented, and
• who has responsibility for making sure this happens

There is more information in this on the post on outgoing communications.

Internal communications also need to be considered in the plan. Now, many of the ways the team communicates internally will already be known, for example through a schedule of update meetings. However, it’s good practice to make sure these are referenced in the plan. Additionally, it is also a good idea to mention in the plan that informal communications are also important, and to encourage people to use them – but to think about how to capture useful ideas or important information afterwards.

Finally, incoming communications should also be covered. There’s no getting away from the fact that these are much more difficult to deal with, and are quite unlikely to come into the project in a structured way. So accept this, but use the plan to formally document the need to be open to these communications, and give the name of someone to whom project team members can take information that comes in like this. This should normally be the project manager.

I must stress that, as I’ve said throughout this mini-series on communications, that the formal methods are very unlikely to be enough. A huge amount of project management revolves around communications, around talking to people and bringing them into the team, around encouraging external suppliers to meet your targets, around making sure your future users know what is happening. Talking is often the best way to do this, but don’t neglect other traditional communications tools, such as posters, newsletters, and so on.

Electronic methods also have their part to play, with email being the one we are most used to. However, don’t neglect social media tools either, if appropriate for your project. You can find out more about those in a series on social media tools for project managers I wrote a while back.

I’ve previously written in some detail about the processes you need to use or adapt in project management, and the steps you need to take to improve the chances of a successful project. But we mustn’t forget that projects end up affecting people, and we need to make sure they are considered as well.

Three weeks ago, I talked about the three broad types of communication we need to consider in our projects – internal, outgoing, and incoming. Two weeks ago, we had a look at the outgoing communications in the project. Last week, we looked at the internal communications in a project.

This week, let’s have a look at communications that are incoming to a project.

Incoming communications are, by their nature, the hardest to try to deal with formally. For a start, you can hardly control how and when people are going to try to talk to you! But this isn’t something you should worry about. In fact, you should welcome it.

There are formal methods of gathering incoming communications, of course. For example, it may be that you have a users’ forum, which allows the future users of what you are producing to provide input into the project. Often, if you have a User Representative on a project board, they will be from, or lead, this group.

Far more common, however, are the informal ways of people communicating to the project. Senior management may chat to your Executive, and happen to mention a couple of ideas for the project. Colleagues of members of the project team may offhandedly say something which suggests a lack of understanding about what the project is trying to do.

These type of communications are incredibly valuable to you. They are the real way that the project can learn about how it is seen by the rest of the business, and how the environment the project is working in is changing.

Of course, we need to find some way of making sure these communications aren’t lost. The best way I have found to do this is to ensure that you, as a project manager, communicate regularly with your team. You should encourage them to let you know what reactions they are getting from people outside the project.

It is important to fight the perception that can arise, both in people inside the project and those outside, that the project is somehow a separate entity, something different from the rest of the business. Remember, all the project is trying to do is achieve something that is for the benefit of the organisation it is part of. I’ve worked on projects where the perception of otherness has taken hold, and rapidly gotten out of hand, and it is definitely not somewhere you want to be – it turns into us and them, with all the conflict that implies, far too easily.

So remember, keep talking, to each other, and to the rest of the organisation. Next week we’ll look at building up a system to enable this to happen effectively, a communications plan, and what this should include.

I’ve previously written in some detail about the processes you need to use or adapt in project management, and the steps you need to take to improve the chances of a successful project. But we mustn’t forget that projects end up affecting people, and we need to make sure they are considered as well.

Two weeks ago, I talked about the three broad types of communication we need to consider in our projects – internal, outgoing, and incoming. Last week, we had a look at the outgoing communications in the project.

Today, let’s have a look at the communications that happen within a project.

The most obvious example of this type of communication are the dreaded update meetings. I’ve written before about my general dislike for meetings, but they do have value as well. They are a very effective means of communication, so long as we make the best use of them that we can.

But while this is the most obvious example of internal communications, it is far from the only one. Other formal methods of communication also exist, be it in highlight reports from the project manager to the Executive or board, or even in the update reports the project manager receives from team managers or external suppliers.

Often, however, the best forms of communication are those that don’t take place in a formal structure – the quick chat in the corridor, the phonecall to query a couple of details, the email fired off late at night doublechecking something. These communications are a way of making sure that you as project manager know what is happening in the project, and that the people involved in the project all have a good idea of what they are doing.

Yes, if a major issue comes up from these informal chats, it needs to be recorded and captured in a formal way, whether in a risk or issue log, or by adding it into a highlight report. But often these chats, and a little bit of guidance, can prevent minor misunderstandings becoming major problems.

The internal communication of the project is one of the best tools you have as a project manager to keep the project on track, to keep the project team motivated and involved, and to bring the project to a successful conclusion. Importantly, this isn’t done by being blinkered into only using formal methods – it’s the friendly word at the right time that is much more useful.

Next time, we’ll look at incoming communications.

I’ve previously written in some detail about the processes you need to use or adapt in project management, and the steps you need to take to improve the chances of a successful project. But we mustn’t forget that projects end up affecting people, and we need to make sure they are considered as well.

Last week, I talked about the three broad types of communication we need to consider in our projects – internal, outgoing, and incoming. Let’s have a look at which parts of this we can do by following a process, and which parts we need to be more flexible around.

Outgoing communications need to be handled carefully, and should be subject to some form of control. This isn’t because we want a project to be a secretive and strange organisation within the business, but to ensure that the right messages are going out – the one thing worse than no information going out is incorrect and conflicting information going out.

For this reason, it is good practice to have a formal communications plan. It helps to ensure that some thought has been given as to who to communicate with, how to communicate with them, what to communicate to them, and how often to communicate with them. In addition, it means that members of the project team are aware of their role in communication, and, just as importantly, what their role isn’t.

The first thing a communications plan needs to do is decide who the audience for communications will be. Remember, the audiences can be many and varied, but the types of communication used can be just as varied. When thinking about the audiences, try to be as inclusive as possible.

Once you have been able to identify the various stakeholders and audiences that need to be considered, it is time to think about the information they need to see, and how they need to get it.

For example, there are some fairly obvious people who need to be kept informed – the people who gave the go ahead for the project to happen, be they a programme board or senior management within the organisation. Many of the communications to them will go through the Project Executive, or be done through formal documents produced by the project team, such as highlight reports.

However, these aren’t the only people that need to be kept informed. The people who will use or be affected by the project also should be told what is happening on a regular basis – if nothing else, frequent communications may reduce uncertainty, nervousness, and possibly even opposition to the project. The communications to this audience are likely to be very different than those to senior management.

Now we know who, how, and how often we are communicating, we need to know who within the project team has responsibility for doing it. As we’ve already discussed, the Project Executive is best suited for communications to senior management, but he will need information you provide as project manager. Possible users, though, may be better off getting information from the Senior User on the Project Board.

These are only examples, and of course will vary from project to project. The important point to take away is that you will need to consider how this is done, and have a plan, rather than muddling through as the project goes. Make sure that for every stakeholder or audience identified, someone has the responsibility to make sure the communication gets to them.

Next time, we’ll look at internal communications. I hope you’ll join me then.