≡ Menu

10 Things I love about managing projects

10 things i love about pm infographic

Click the graphic to see it full size.

10 Things I love about managing projects

  1. The variety. Today, IT, tomorrow talking to Marketing. Every day is different!
  2. Leading a team. Teamwork makes the day more interesting.
  3. The tech. Getting to try new apps.
  4. Problem solving. It’s satisfying to put things right.
  5. Introducing new things. Delivering change is fun!
  6. Communicating. There’s lots of talking and writing to do.
  7. Delivering value. I can see how my contribution makes a difference.
  8. Transferable skills. Future-proofing my career and making myself more marketable.
  9. The other people. Access to different teams to see the whole business.
  10. Flexibility. Working from home or office.

What is the best thing about managing projects for you? Let us know in the comments.

2 comments

The definitive guide to project success criteria

Definitive guide to Project Success CriteriaI get asked about project success criteria a lot – in fact, it’s one of the most searched terms on this site. So I thought it was about time that I pooled all my resources into one definitive guide to project success criteria.

And where better to start than with a definition of what project success criteria actually are:

Project success criteria: a definition

Project success criteria are the standards by which the project will be judged at the end to decide whether or not it has been successful in the eyes of the stakeholders.

OK, glad we got that sorted. Now let’s look at why we should care about project success criteria.

Why are success criteria important?

Organisations don’t define failure. We don’t document how we will know if a project has failed – what failure looks like – because thinking about failing is not a good way to motivate the project team when the work has only just started. The absence of a formal definition of failure makes it uncomfortably easy for internal and external stakeholders to brand projects a failure.

Think about some of the projects that have hit the headlines recently (in any country). Projects ‘fail’ in the eyes of the media and stakeholders because for people are left to guess what success looks like. Is it delivery on time? Is it delivery on budget? Perhaps those two things really don’t matter much to the stakeholders concerned if they get a great quality result and happy customers.

Successful organisations take the guesswork out of this process: they define what success looks like, so they know when they have achieved it. If you want project success, you have to define what success looks like for your project. Perhaps budget is the most important thing to your stakeholders, and quality is taking a back seat on the project. Perhaps customer satisfaction is essential, and you don’t care how many overtime hours the team has to work to get that end result.

Project success criteria are a great tool to use to manage stakeholders and to generate engagement. You can use them to define the project’s goals and track progress – and if your stakeholders stop caring about your success criteria you’ve got an early warning sign that you need to do more to continue to keep them on side.

Project success criteria are the standards by which the project will be judged at the end to decide whether or not it has been successful in the eyes of the stakeholders.

Whatever success looks like, you have to define it so you can own it. There are two types of success criteria that you’ll need to define for your project.

Two types of project success criteria

So you want to know how you’ll know if your project has been a success? You need to identify what success looks like for you and your stakeholders. And the easiest way to do this is to brainstorm with your team.

During this process you’ll probably come up with success criteria related to the management of the project. These are the success criteria which you can refer to in project audits or the post-project review. They help focus your mind on the ‘business’ of project management and relate to doing the project right. They help you check that you’re hitting all the right targets and are applying project management standards appropriately. Examples would be things like:

  • Hold a Project Board meeting once a month
  • Complete project audits in line with the timetable published by the Project Office
  • Ensure all timesheets are completed by the deadlines
  • Achieve 95% compliance on project quality reviews.

Alone these success criteria are not sufficient. They help you measure whether you’re doing a good job but not whether you are actually delivering anything useful for your stakeholders.

Your success criteria analysis should also identify deliverable-based project success criteria which are strongly linked to the business case and the rationale behind doing the project. It’s hard to give sensible examples as they are tied so tightly to what your project is delivering but you should aim for things like:

  • Achieve rollout of software to all users
  • Train 95% of staff within the two week training period
  • Improve customer satisfaction by 65% over the first three months
  • Gain Centre of Excellence accreditation for Marketing department.

You get the picture.

So, to summarise:

  • Project management success criteria: Related to the professional job of running the project e.g. Produce and gain sign off for project initiation document
  • Project deliverable success criteria: Related to things delivered as a result of the project e.g. Distribute 6,000 instructional leaflets to households in our target area.

Document your success criteria

Document your project success criteria in a list. I include the list in the Project Charter or Project Initiation Document so it’s easy to refer to.

Each list item should include:

  • Name of success criteria
  • How it is going to be measured
  • How often it is going to be measured
  • Who is responsible for measuring it

You can also capture the output of the measurements here if you want, or move that to another relevant project document. Personally I like to keep them separate, but I don’t see why it wouldn’t work to have your records all in one place.

Documenting your success criteria also means that you can get project stakeholders to sign up to them. Having them clearly recorded makes it easy to refer to them later and there is no ambiguity about what you set out to do.

Of course, you can change them later, add a few more or take some away if the project evolves.

How to measure project success criteria

You have two choices when it comes to measuring project success criteria:

  • Discrete: Yes/No
    We did or did not do something
    Examples: Project delivered on time, company gained XYZ accreditation, new branch opened
  • Continuous: measurable on a scale
    We did something to a certain extent, within a target range
    Examples: Improve customer satisfaction scores to between 75 per cent and 100 per cent, increase revenue by 8-10 per cent, rebrand 15-20 offices within Quarter Four.

Continuous measurements always include the possibility of being translated into discrete targets. If customer satisfaction was 75 per cent in May, and the target was 60 per cent, you reached the target. If it was 59 per cent, you didn’t. Monitoring benefits on a continuous scale is always better as it allows you to track changes over a period of time. If the customer satisfaction target was reached in May, that’s fantastic. But you cannot tell from a yes/no measurement if it was better or worse than April or what the trend into June is looking like. So go for continuous measurements wherever you can.

Baselining performance

It’s great knowing how you are going to measure success criteria going forwards, but how are you doing today? If you want to capture trending information then you have to take a baseline of current performance as soon as you can, preferably as soon as you have set the success criteria. The problem is that at the beginning of a project there’s normally so much going on that baselining current performance takes a back seat to doing improvements and delivering change.

Still, make time for it, or you’ll have a harder job later working out whether your project has made a difference. It’s great knowing that you are now calling back customers within 20 minutes, but if you don’t know what the call back time was before project was implemented you may very well have made the situation worse – you just can’t tell.

A performance baseline lets you identify the differences in performance in the post-project world related to the things you consider important measures – your project success criteria. Use the same calculations and tracking method to work out your baseline performance as you intend to do for measuring your success criteria later. Otherwise you are introducing even more variables into the mix – keep it simple.

When do I track success criteria?

You’ll take an initial performance benchmark as soon as you can in the project, as we saw above. Then you have to work out how often you want to measure your project success criteria. I think that each success criteria will have different requirements. Some you can track once a month, others you’ll only measure once more. Some you won’t track very often and then as soon as you hit delivery you might be measuring them daily (like daily quality targets or call handling times). For help on what you should be reporting regularly, get my e-course and ebook on Better Project Status Reports.

Project management-related success criteria do not need to be tracked over time and so you do not need to generate a baseline of current performance. Once the project or task is over you should be able to say with certainty whether or not, and to what extent, you met the criteria. Did you hold those Project Board meetings monthly? I hope so. But if you didn’t, the project is over and chances are no one cares anymore.

The true business benefits, on the other hand, hopefully last for a lot longer. Even a one-off project like changing all the office light bulbs to energy efficient ones has durable benefits. The success criteria could be: ‘maintain electricity savings at 40 per cent of previous expenditure for three years.’ The measurement of these over time should be handed to the operations team as part of the project handover when the project closes. You should not keep the responsibility for tracking success criteria (i.e. project benefits) over time. While the project is running, report on your progress so you celebrate the successes as you go. And if there aren’t successes to celebrate, so you can adjust your project approach so that you do hit your success criteria.

Project success criteria: the summary

To summarise:

  • You must define what success looks like for your project or you won’t know if you have achieved it.
  • Success criteria measure what’s important to your stakeholders.
  • Document success criteria and get everyone to agree to them.
  • Use continuous measurements where possible.
  • Baseline today’s performance so you know where you are starting from.
  • Track as appropriate and report on your progress.

Is there anything you would add to this list? Let us know your thoughts on project success criteria in the comments below.

1 comment

5 Tips for Managing Project Communications in a Crisis

In this video I look at project communications during a crisis (text summary below).

For those of you who prefer reading or who can’t watch the video, here’s a summary:

There are always things that go wrong on projects – sometimes those issues are small; sometimes they are significant. Here are 5 tips to help you deal with project communications during an issue.

1.     Have a single point of contact

Appoint a single point of contact to deal with communications during the incident. That could be you or someone else from the project team, but make sure everyone knows who to go to for communication updates and who will be asking them for status reports. This person is dedicated to running the communication for all the stakeholders.

2.     Deal in facts

There will probably be quite a lot of emotions during a problem – people have an emotional response to what has gone wrong. Strip that back and deal with what you know to be true.

3.     Deal with what people are worried about

You might be dealing with something behind the scenes, such as a software bug, but your end users might be worried about something else. Don’t dismiss these views as unimportant. Those concerns are valid: listen to what those people are saying and deal with what is bothering them, even if that means you are splitting your efforts between fixing the behind the scenes problem and dealing with concerns from your users.

4.     Be fast

Get your messages out there as quickly as possible. It’s the best way to squash gossip before it starts.

5.     Plan for power down

Think about how you will deal with project communications if you don’t have electricity. It happens: power lines are cut through and generators go down. When you can’t rely on email, instant messaging or people being in front of their computers, how are you going to get the messages out?

View all my project management videos on my YouTube channel here.

0 comments

Top Tips for Breaking into Project Management

52 Tips to break into PM“What advice do you have for project management students fresh out of school who want to break into the discipline?”

That’s what Geoff Crane asked me, and other project managers, so he could compile our top tips for his students. I found it quite difficult to come up with some tips because there are so many things that I could pass on to new project managers. In the end, given the space constraints, this is what I came up with:

New project managers should show that they are flexible, willing to put in the time and able to listen to their project team members. As you don’t have much project management experience, look for other ways to contribute, such as through facilitating discussion, being great at documentation, being honest and transparent in communications and asking the questions that no one else dares to – I do this a lot and when you are new to a business or a job you can get away with it simply because you are new!

One of my first projects I forgot to identify a stakeholder group and didn’t talk to them at all. Then on go live day I had the head of that department on the phone wondering what had happened and why her team was swamped with extra work. Communicate more than you think you have to – extra stakeholders will appear where you least expect them. That doesn’t mean blanket emails to the whole company. It means tailored, relevant communication to specific stakeholders, but lots and lots of it. Phone people, stop by their offices, invite them to lunch or coffee. Especially on big projects, people do worry about not knowing what’s going on: it’s your job to stop that.

People do worry about not knowing what’s going on, especially on big projects. It’s your job to stop that.

Another unwritten rule of project management is that you protect your project team from politics and grief so that they can get on and do their jobs. If it helps, take the blame for problems yourself. It’s a great way to diffuse tension and help people move on to constructive problem solving. It is very hard for someone to keep shouting or ranting at you when you’ve apologised.

Finally, don’t forget that you are a project stakeholder too: you should always get something out of a project in terms of career development, even if it is just spending another 6 months working in an area you love.

Geoff put together a whole ebook. You can download it for free with a single click here. It’s a PDF document (no sign up required).

4 comments

Reinventing Communication [Book review]

Reinventing Communications Book Review“If we spend 90 percent of our time on communication, it makes sense to have a method to figure out if we are spending out time wisely and, if we are not, what we can do to improve communication,” writes Mark Phillips in his book, Reinventing Communication. That sounds sensible, so I was keen to read more.

Reinventing Communication isn’t a soft skills book. There’s nothing fluffy about it as it aims to follow a scientific approach. This is an interesting concept for something that has traditionally been seen as a project management soft skill – Phillips says it can be used as a performance management tool.

The new language of project communication

“This approach can help non-soft-skills oriented people think about the importance of communication and recognize the effect it has on project performance while providing a clear way for them to make their communication more effective.” Mark Phillips

The book is quite technical and there is a large new vocabulary to learn. He writes about Planned Communication (P COM), Actual Communication (A COM), and Communication Variance (COM V). COM V plus schedule performance indicates that a project is performing as planned with less than the planned amount of communication i.e. the team are efficient. As you can imagine, Phillips places a high value on EVM for communicating status as this fits with the analytical, data-based approach he advocates.

How practical is this?

Some of the ideas sound theoretically quite good but to a practitioner simply don’t seem workable. I’m not honestly sure, for example, how I would work in an environment where the project communications plan mandated the maximum number of emails I could send per week. How does that work in practice if a major issue hits and I need to do something about it? Phillips writes:

“We can also apply simple arithmetic and see whether the quantity of communication leads to a particular pattern of behaviour. For example, will sending 10 emails to my customer have them get back to me any faster? We can apply more advanced analytical methods such as studying word choice or the emotional tone of an artifact and see whether these make a difference in how people behave.”

We could, or we could just get on and manage the project. I doubt many project managers have time to do a controlled experiment about tone of voice in email, sending two different versions and seeing which group gets on with it faster. And how would you know if other factors were at play?

The book includes a checklist with steps to take to implement communications as a performance management system on your project. It’s step by step so this is useful, and it includes a reminder to translate the output of each step into measures. I understand the benefits of setting this up as it helps identify project problems early, based on observable and measurable phenomena, but the whole thing seems very clinical.

Phillips does acknowledge that projects are each different. There is no single right answer, because much of project management is defined by the people and environment. “We need to recognise that a project is a social environment,” he writes. Therefore you have to tailor project communications to account for the environment.

I have to confess that I struggled to stay awake while reading Reinventing Communication. That’s partly because I’m sleep-deprived with two babies in the house, but partly because I found the book’s theoretical style heavy going.

It’s interesting in an academic way but for practitioners? I’d like someone else to implement communications as a performance management tool on their project to give me real life proof that it works. If you try it out, let me know!

Reinventing communications book coverRight to reply

I asked Mark for his comments on this review and he said:

“One of the reasons behind the book was to challenge existing perceptions of communication as a soft skill so I was quite pleased to read that it did. I’ve tried to bridge the gap between the community that can execute effective communication as a soft skill (like yourself) and the community that could so much benefit from improving communication, such as engineers who became project managers or KPI/metrics focused managers. The idea behind the approach is to demonstrate the importance of communication through measurable data.

“Existing research into the importance of communication overwhelming shows how important it is in a general sense. I hope to empower project managers with the tools to prove its importance on their specific projects.

“Another goal is to show project managers how they can actually improve their communications, in a measurable way, without having to be masters of soft skills, which can be difficult for some people. I’ve done this by focusing on measurable aspects of communication, such as the total number of emails sent to a client in a week. For example, this aspect of communication, the total amount broadcast out, has been shown to make a difference in the effectiveness of communication. If a project manager consistently sends 10 emails to a client each week and doesn’t get the responses they need to meet deadlines, they can look at reducing the number of emails and seeing if that makes a difference. This approach can help non-soft-skills oriented people think about the importance of communication and recognize the effect it has on project performance while providing a clear way for them to make their communication more effective.”

Thanks, Mark, for taking the time to respond.

Buy on Amazon.co.uk
Buy on Amazon.com

0 comments

9 Project communications you should have sent this year

9 project communications you should have sent this yearA few weeks after I started back at work, one of my long time stakeholders sent a message to someone pretty high up the hierarchy saying ‘project communication was so much better when Elizabeth was around’. It’s nice to hear people say I was doing something right, although it was a bit of a shame that she hadn’t realised I was already back at my desk. I guess I didn’t do much communicating during those first few weeks.

Good communication on projects is so important, and something that it is useful to reflect on at this time of year as we establish areas for improvement in the coming 12 months. Did you send any of these project communications during 2014? You should have done.

1. We have uncovered an issue but…

When something goes wrong you should ‘fess up as soon as possible. However, senior stakeholders like it when you can tell them what you are doing about the problem.

If you faced a problem this year you should have presented the issue along with your solution or recommendation.

2. We’re on track for…

You should have kept stakeholders informed at all stages along the way. Letting them know that things are on track helps them feel confident that the work is progressing as planned.

This is different to the ‘reporting by exception’ model. In my experience, that only works for a short time. When people stop hearing positive noises after any length of time they attend to assume the worst, even if you’ve told them that you will report by exception.

3. I’m sorry…

How many times did you apologise this year? Lots, I hope. (OK, not that many.) You can cut through a lot of conflict and office politics with a well-placed, sincere apology.

4. The current status is…

I hope you used regular project status reports this year. You should have used them as a tool to communicate status on your project, at least once a month, at least to the project sponsor. Preferably more.

Need some help improving your project reports for 2015? Take my online project reporting course and get people to actually do something as a result of reading your status updates.

5. I saw this and thought of you…

Make connections. As a project manager you are well placed to see what is going on in various areas of the business. Link people together, make introductions, pass on information that you think others would find useful.

If you didn’t do this during 2014, read these 6 reasons why networking is important and see if I can change your mind for next year.

6. Thank you for…

For coming to my meeting, for giving up your resources to help with testing, for passing me that great contact, for being such a great project team member.

There are dozens of reasons why you should have said thank you to the people you worked with this year. I hope you took every opportunity.

7. That didn’t meet my expectations of…

Sometimes we have to communicate the bad news, and if you don’t speak up you won’t ever seem improvements. When a team member doesn’t perform as expected, talk to them about it (and not via email). It’s not personal. You had expectations, they didn’t meet them. Discuss how you can both get a better result next time.

You should have done this with suppliers as well. Don’t put up with bad service because you are too worried to say something.

8. I need…

Did you get the resources you needed to complete your project tasks successfully? No? Did you ask for them?

Don’t expect your project sponsor to be a mind-reader. If you want more people, more money or more time, ask for it. You might not get it but at least you have tried!

9. If…then…

You would have made a lot of decisions this year. Did you always take the time to explain why you put forward that particular recommendation? You should have explained the consequences of your decisions in business terms, so that stakeholders and project team members understand why you’ve opted for that route forward.

Which of these phrases will you aim to use more frequently in 2015? Share your thoughts in the comments below.

3 comments

Ace the PMP Exam [Book Review]

When I first wrote [amazon text=Social Media for Project Managers&asin=1935589113] the publishers put 'Elizabeth Harrin, PMP' on the cover. I had to get that taken off - I'm not a PMP, although I feel very familiar with the PMBOK Guide® concepts. It's simply something I've never got round to doing. I might at some point in… Continue Reading->

10 Things I love about managing projects

Click the graphic to see it full size. The variety. Today, IT, tomorrow talking to Marketing. Every day is different! Leading a team. Teamwork makes the day more interesting. The tech. Getting to try new apps. Problem solving. It's satisfying to put things right. Introducing new things. Delivering change is fun! Communicating. There's lots of… Continue Reading->

Free project action log template

My To Do list is massive. So I have developed an action log to control my tasks. I copy and paste actions from conference calls, steering group meetings, team meetings and those chance conversations you have in the corridor into this. I can filter it by task owner when I am talking to someone and… Continue Reading->

Giveaway: Get Fit with the Lazy Project Manager

I interviewed Peter Taylor, otherwise known as The Lazy Project Manager, last month. He shared some tips on how to manage project health checks. I have a copy of his book, Get Fit with the Lazy Project Manager, to give away. Contact me with the phrase, "I'm a bit fit" and I'll add you to… Continue Reading->

What George Orwell Can Teach Us About Project Management

This is a guest contribution by Mark Phillips, PMP. “What is above all needed is to let the meaning choose the word, and not the other way about.” George Orwell George Orwell’s essay, Politics and the English Language, is the last essay in his wonderful Penguin Book called “[amazon text=Why I Write&asin=014101900X]” In the essay… Continue Reading->

Women in IT Awards: the results

The inaugural Women in IT Awards were held in London on Thursday and I’d been nominated, with my colleague, for work on a large IT transformation project at Spire Healthcare (the project forms the major case study in my book, [amazon text=Customer-Centric Project Management&asin=1409443124]). This photo is of us just before dinner was served. It… Continue Reading->