Recently, I wrote about a preliminary study that had been done attempting to compare the value of various project management qualifications. I pointed out that, at least in part, it seemed to comparing apples with oranges, in that one qualification considered (PRINCE2) doesn’t try to sell itself as a general project management qualification, but specifically as a qualification in implementing one particular methodology.

But there is a wider issue here. The explicit statement was made that those qualifications which require longer levels of experience before being awarded were inherently better than others. I think the important point to consider is: better for whom?

Some of the bodies involved with project management at the moment are perfectly clear that they are trying to professionalise the career. When I say this, I am trying to use the precise meaning of professionalisation. This is not a matter of taking pride in your work, of always trying to do the best you can. No, this is about defining a set of formal requirements that someone must meet before they can even become a project manager. It is, in effect, an attempt to raise the barriers for entry into the profession considerably.

On the one hand, this is fantastic news for project managers who meet these requirements. By raising barriers to entry, they naturally decrease the total amount of people considered project managers. By decreasing the supply of project managers, it is likely, almost inevitable in fact, that the average salary of project managers will rise. I make no bones about it, professionalisation of a career is very good news financially for people in that career.

But the flip-side of this is that there are costs to the rest of society for doing this. Traditionally, these costs have been tolerated and accepted because society also gains a benefit. Let’s consider some of the traditional professions. Medicine is highly professionalised, allowing doctors to charge more, but that is accepted because the cost of having amateur medics running around was very high. The law is professional, because there needs to be a defined set of rules, and people who can interpret these rules, to allow society to function effectively.

Over time, as society has become more complex, more and more careers have professionalised. Accountancy, architecture, engineering, dentistry, and so on, become professions. It is possible to point at all of these and see how the benefits to society have developed, meaning the higher financial costs are accepted. Importantly, it is also possible to see how there were few external factors, other than the drive from within those careers, for regulation, of which professionalisation is one. Often, in fact, there is a pressure against professionalisation, and regulation, because the upfront costs would be lower (as generally people are poor at taking into account the future costs of, for example, a poorly engineered bridge).

We can see, then, that professionalisation can be seen as a deal between a particular career and society – if society is willing to pay more, they will, overall get a better service, to the benefit of all.

But, importantly, in those cases there were no other clear and immediate external pressures to ensure quality. Yes, poor medicine will cause problems, but often only after a significant time has passed. The punishment for accepting poorer work came much later than the reward of getting a cheaper deal.

With project management, however, I am not sure whether this holds. Often, poor project management will lead to a relatively quick poor result, as the project fails, or costs rise dramatically. Organisations that use project management already have a significant incentive to ensure good project management, because the cost of poor project management is quickly felt.

What this means, then, is that there is already a significant pressure on project management to be good, and effective. Is, therefore, a move towards full professionalisation something that would be welcomed by the rest of society – if society is already paying for good project management, because it is in their interests, would they really want to pay even more as the career raises the barriers to entry through professionalisation?

I’m not saying here that the professionalisation of project management is a bad thing. I am saying it needs to be considered. Some of the best project managers I have met are people who never expected to start out on that career path, but instead, after a period of years or decades doing something else, they were able to enter the career, bringing fresh thinking, and new techniques, which ultimately end up enriching all of project management. Would they still have done that if there was a major barrier for entry later in their career? How many people do you know who train to become a doctor in their forties?

Professionalisation would have benefits to the project management career, but we’d be foolish to think there weren’t also costs. Excluding effective people from outside is a cost. Even the higher salaries could be a cost, if they simply turn some businesses away from innovating with new projects.

What we as project managers have to do is make sure we go into this with open eyes. And if professionalisation is a path the career wants to go down (and, frankly, once the process has begun, I don’t think it could be stopped even if a significant number wanted it to) we need to remember that this is a deal between us and society. That means we need to be better at showing what the benefits of project management, and of people experienced in it, are, not only to the business we are directly working for, but to wider society.

In essence, much as professions such as medicine and the law have a wider duty to the public good, project management would need to as well. That means a clear formulation of what that duty is would need to be distilled, and that, when asked to do something that goes against it, we would have to be willing to say no.

I’ll be honest, I’m not sure what that formulation would look like. I’m open to suggestions.

How do you find out the requirements for a product in your project? How do you find out how long a certain task will take? How do you make sure your Executive is up to date with where the project is?

Communication is a vital part of project management. To me, it is the most important part. Without good communication, you won’t know whether you are on track, or miles off course. Without good communication, issues can arise that completely surprise you. Without good communication, you won’t know what your project is supposed to achieve.

There are many tools and techniques you can use to improve communication. I’ve talked about some of them in my series on social media tools for project managers. But sometimes it’s important that we go back to basics. And the most basic communication tool we have is talking.

Talking is fantastic. When you are face to face, you can really explore issues, you can tell when there is a pressure point that needs to be discussed, and you can rapidly get to the bottom of any issues. Talking is an amazing tool in our arsenal, but one too many project managers don’t use enough.

Emails and status reports are useful, but they can never beat a good face to face talk. Get out from behind your computer and talk to your team.

Last time, I talked about my hardest project, the production of Understanding Project Management.

The work was hard, but so far feedback on the sneak preview has been good.

The whole process has also given me a new insight into the difficulties faced by our team members. If they are too personally invested into what they are producing, they may shy away from working on the difficult areas, the parts they are concerned about. This is particularly true if you are part of an organisation that has a low tolerance of failure among its staff.

As a project manager, you need to make sure that your oversight of the project let’s you spot these problems early, and that you make sure the project environment is one that supports the team – even if they do make the ocassional mistake.

Ultimately, any project will be better if the team members know they have the opportunity to try new ideas, and won’t be berated for failing. As I keep saying, all projects feature change of some sort, and all change involves some risk. Don’t be surprised if sometimes risks actually occur, just be prepared to help everyone fix it.

Last week, I wrote about a difficult project, and asked you what some of your hardest project was. I also promised I’d tell you about my hardest project, and here it is.

My hardest project is actually a small one. Just one person was needed to do the work on the product, and the project management of that work took only a small amount of my time – theoretically. In fact, I found myself spending longer and longer on the planning of the work.

Soon, the project management load of this one small project started to crowd out other work. I spent more and more time assessing the risks the project faced, planning what tasks needed to be done next, and thinking about quality tests.

The reason for all this was, of course, that I didn’t want to face the person who was supposed to be actually doing the work, and hadn’t been. Mainly because that person was me.

The project I am talking about is one I’ve mentioned a couple of times here. It is creating an information product, a simple course to help you get the foundations of project management clear.

As I was writing it, a strange thing happened. Despite being pretty confident in terms of my knowledge of project management, I started to become more and more uncertain about what I was writing. Doubts would beset me, from everything from the concepts I was explaining to the words I was using to get my message across.

Now, I know this is a pretty special case when it comes to project management, because the Executive, the PM and the team are all the same person. But I still think I’ve learnt something from the experience.

Because, like any human being, I had some self-doubts, I retreated into something I was comfortable with, something which I knew I could do well – in this case, project management. The actual work of writing what I had planned to was getting pushed aside so I could focus on what I did well – even if that didn’t actually move the project along.

Luckily for me, the thing I am good at was also the thing telling me I wasn’t making progress, so it was pretty difficult to ignore. (Though, believe me, I made a good stab at it.) Eventually, I forced myself to knuckle down, to step out of my comfort zone and work on what needed to be done.

I’m actually pretty happy with what I’ve produced, and you’ll get the chance to judge for yourself. I’m releasing a sneak preview today, and you can go to this page to download it. (I hope you like it!)

Project work can be tough. Project management can be really difficult, and take a lot out of you. I’m sure you’ve all had your fair share of tough projects, but can you remember your hardest one?

I remember one of my most difficult was a major infrastructure rollout project. It involved people within the business, and a contract with a large external supplier to provide most of the technical work.

Everything went fine through the procurement stages of the project, when there was a tight team inside the business. Once we actually got to the rollout stage, though, problems started to arise.

The problems were nothing that couldn’t have been expected, and the kind of thing that happens with any infrastructure work, particularly one which requires civils work (digging of trenches, gaining permission from landowners, and so on). Delays occurred, because delays will always occur when you are dealing with numerous separate organisations, all with their own drivers and timescales.

Unfortunately, I was a relatively inexperienced project manager, and had an Executive who was even more inexperienced in project work. I failed to explain adequately the realities of project work, and his frustration with the project diverging from the original plan made a year ago grew and grew.

Ultimately, this led to the Executive attempting to impose the management style he used internally onto the external supplier, who was not happy with this. The loss of trust and the breakdown of the relationship meant the rest of the project was a constant battle.

That project taught me that managing my Executive was at least as important as managing my team (something Elizabeth Harrin talks about in a recent blog post on managing up). But the price was a stressful and unpleasant year or so, for me and the rest of my team, and extra work trying to repair relationships and morale on an ongoing basis.

Believe it or not, that wasn’t actually my hardest project! I’ll tell you all a little about that in a future post, but I’m curious as to what you have found to be your hardest project. What happened that made it so hard? What did you learn from it? And what would you do differently now?

Photo courtesy of stuartpilbrow. Some rights reserved.

This is a very quick (3 minutes) TED video from Terry Moore, which just goes to show you should never dismiss the possibility of learning a better way to do something you think you already know everything about!

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.