Last week, I was fortunate enough to present to PMA Focus, a project management conference organised by Projekt Management Austria. My talk was on whether social media could really deliver for project management, and is above. I have included my planned transcript below.

Read more »

“In theory, there is no difference between theory and practice. In practice, there is.”
– Yogi Berra. Or Albert Einstein. Or Jan L.A van de Snepscheut. Or…

Sometimes, we all get too caught up on the theories behind project management. Which process should we follow? Do we need to get certification from PMI, or in PRINCE2? Should we be using Kanban, XP, Agile, all of the above?

But it’s important to remember that the theory is only important when it helps with the practice of project management – in other words, when it actually helps us get projects done, quicker, cheaper, better.

That’s why Lean from the Trenches by Henrik Kniberg is so useful. It isn’t trying to tell you the one true way of managing a project. It isn’t setting out exactly what you should do so your project can be classed as Lean. It isn’t a set of prescriptions on what you must do.

What it is is a description of one particular project, over one particular span of time, and the way that it was managed during that period. It lets you know the successes, and the difficulties, so you can see for yourself what worked and what didn’t.

And, as always, reality is much messier than the textbooks would have you believe. The project described, a large-scale software project for the Swedish police, is complicated and high-profile. The project team increases in size dramatically over the period this book covers. The release schedule doesn’t fit with the theories.

But… it works. It delivers. And that’s the most important thing for any project – delivery.

Kniberg explains what was done to help the project’s management, and how it worked or didn’t. It covers, very briefly, the key ideas behind Agile, Lean, Scrum, XP, and Kanban, but goes beyond them, showing you the way they were applied, tweaked, and adjusted to meet the needs of the project.

The story told of the project is interesting, and should spark ideas that go further than the theory alone. The way the principles behind the various Agile methods are applied offers greater understanding.

For myself, as a relative novice when it comes to purely software projects, I found it the most useful project management book I have ever read. If you want to get better by drawing on the experience of others, read this book.

Purchase on Amazon.com, Amazon.co.uk.

Crunch times are a sign of failure of project management, not a way of catching up.

I was bleary-eyed as I finished the last of the typing. I did a quick spell-check, and pressed print, trusting that the chugging of the printer working away would be enough to keep me focused as I prepared the binders and envelope.

I needed the printer to keep me focused as I was tired. Very tired. I’d worked until 5 in the morning, then got up and got back to work by 8:30. This was a tough crunch, a period of intense work to get something finished by the deadline.

I was doing this because I’d made a mistake. I’d misread the date this tender response had to be returned by, and thought I had two more days than I actually did. When I finally noticed my error, the only way I could make sure I was finished in time was to work very, very late.

Doing this made me think about the other crunch times I’d been involved in on other projects. I remembered the late nights working in an empty office building, because as the project officer the work of sorting, filing, and burning project documentation onto CDs had been left to me – but no-one had thought to finish all the documentation they were writing until the day before everything had to be done.

I remembered the nights we worked into the early morning in the boardroom, two sets of negotiators thrashing out a contract, the arguments for and against various clauses getting less coherent as the night wore on.

I remembered my first time as a project manager, demanding that my supplier throw more resource to deliver a complex infrastructure for the date marked on my plan, not a week later.

All these memories, and my current predicament, had one thing in common. They all happened because of a mistake.

As a project officer, I had had to work late because the project manager hadn’t considered the preparation time to ensure we could present our documentation for our project assessment – yes, he’d made sure there was time for the documents to be written, but there was a need for additional effort to deliver them properly.

Working in the boardroom into the early morning happened because we hadn’t included enough time for negotiations in our project plan. We were carrying out negotiations with four possible suppliers at the same time, and that meant to meet the timescales that had been set for us, we either shortchanged each supplier, or the project team had to work into the early hours day after day, week after week.

My demands to a supplier that they throw more resource, of people and money, at a delay to make sure we met the date on my plan was due to my earlier mistake of letting my executive, and the rest of the business, believe that a project plan could be written that predicted the definite end date of a project a year in advance. I was too inexperienced to realise I needed to go back and explain the changed end-date – after all, a week’s slippage on a year long project is not bad at all.

And that’s the thing with crunch times in projects – usually, they are caused by a mistake. Sometimes, like last week and my tender response, they are caused by a mistake that you can’t do anything to fix. Then you can’t get away from the crunch, but you can learn from it to make sure it doesn’t happen again.

Other times, like when I demanded the supplier put in more resource, the mistake can be fixed. In that case, it was a matter of realising much earlier that our plans and schedules need to be flexible, and adapt to changes on the ground. A plan can’t be a prediction of the future, it can only be a guide to our route – and one that we need to adapt as we go along.

Avoiding crunch times means you are less likely to burn-out yourself or your team, and that your work will be of a higher quality – if you’re working on something when you’re tired, you are more likely to make errors. Sometimes you’ll catch them, and end up doing even more work to fix them. Sometimes you won’t, and they’ll end up in a poor quality output.

So the next time you feel like you, or your team, have to start putting in more hours, coming in at weekends, or otherwise somehow putting in extra effort, ask yourself what the root cause of this is. Is it something you can’t avoid this time – but can learn from to avoid in future? Or is it a case of not realising the deadline can be moved to reflect reality?

(Image courtesy of timsackton. Some rights reserved.)

It’s the people we work with who get projects done, but sometimes we don’t act like it.

When people talk about project management, a lot of the time they only seem to focus on the easy bits – the processes, procedures and methodologies. I don’t mean that these are simple to do, but they can be written down, tweaked, and agreed upon – they are easy to discuss.

What is less simple is team management, which is more important. No matter how good your plan, or how impressive your documentation, if your team aren’t committed to it, or just don’t know about it, then your project will fail.

That’s why I was interested to read two recent articles from Elizabeth Harrin’s blog, A Girl’s Guide To Project Management. They deal with the concept of team coaching, and what team leaders and members can do to help a team work well together.

The articles are an interview with Phil Hayes, and a review of his book. There are some interesting ideas in there, and they are certainly worth a read.

Personally, I think the only thing I’d add (or at least make more explicit) is the importance of trust within a team. All team members, including the nominal leader, need to be able to trust one another. As a project manager, I always try to demonstrate trust in my team by leaving them in peace to get on with assigned tasks, and by treating their concerns seriously.

This doesn’t mean I cross my fingers and hope work gets done – there are still regular update meetings. But this is about making sure everyone on the team knows where we are collectively, and is aware of any issues (and can suggest possible solutions!), and not an adversarial check on what they’ve done.

For my part, I try to show their trust in me is valid by dealing with problems promptly, always being available to help remove obstacles in the path of their work, and most importantly, letting them know I have confidence in them to get the work done.

I find once the team realises the project is a safe, shared environment, they are able to collaborate, and contribute, much more freely and effectively.

What about you? What are your tips for team management?

(Image courtesy of toffehoff. Some rights reserved.)

I read an interesting blog post the other day, called How Consensus Decision-Making Creates Shared Direction in a Team. The gist of the article is that for a team to be highly energised and committed to their work, they need to share a sense of direction.

Now, I have to say that I broadly agree with that. When working with a project team, one of the most important things you can do to build that team spirit, and the commitment to work through the problems that will inevitably arise, is making sure everyone knows the end goal, and wants to achieve it.

But I don’t think it is possible to get 100% consensus on every decision, every time. Sometimes it may just be that there isn’t time to go through all the other options to come to the full consensus. This is unfortunate, and if at all possible you should seek to make the time.

Other times, though, it will be because the people in your team also have competing and conflicting aims. The nature of a project team means you are likely to have people from many different areas of the organisation, and some of their aims may be different to the aim of the project.

For example, I recently worked on a project to completely change the way printing was handled across an organisation. The aim of the project was, ultimately, to save the organisation money, by eliminating excess capacity, and expensive processes used. One of the areas of excess capacity was in an internal print unit.

Now, the person who lead the team responsible for the internal print unit had, not unnaturally, a desire to protect her team from any possible cost-savings, and, ultimately, from possible redundancies. This is a perfectly natural desire for a manager who has worked with their team for many years – but it was at odds with the aim of the project.

One way of dealing with this would be to simply exclude that person from the team – if they have a competing goal, it makes no sense for them to be involved, right? But that person was also a source of valuable information about the current situation, the demand they currently deal with, and so forth. For the project to be a success, that information was needed and so, in at least some way, they needed to be part of the team.

So if exclusion is not an option, and you can’t reach consensus on the way forward, what do you do?

Well, then someone has to be the bad guy. Someone has to make the decision about what is the right way forward for the project. That means taking account of concerns about other areas, certainly, but it also means having to make a decision that some in the team may disagree with.

Of course, this is an awful situation to be in for the dissenting member of the team, and it’s important you understand that. But the project is working to provide a benefit to the organisation as a whole, and sometimes that may mean certain parts of that organisation suffer. Someone needs to make the decision to move forward.

It’s not nice, it’s not fun, and I hope it’s not just a desire for alpha male behaviour coming through, but sometimes you have to be the bad guy – and be willing to take the fallout from that.

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.

Project communications are important in a number of ways – don’t neglect any of them.

There are a few ways that we need to be comfortable communicating when we are managing a project. Clearly, we need to enable effective communication within the project, so that team members and others have the information they need about what everyone else is doing to ensure their work remains on track, and fits in with everyone else’s.

But we also need to deal with communication going out of the project – every project I have worked on has had an element of communicating what the project is about to those outside. It’s about making sure that the mysterious organisation called the project doesn’t stay mysterious for long, and the rest of the business (who, ultimately, the project is designed to benefit) are aware of what the project is doing, and why.

One final aspect that is sometimes forgotten is being aware of communication coming into the project. The most obvious example of this is the communications being passed down from the Project Executive (or Sponsor) about the environment the project is working in. After all, this is part of their role – to be able to interpret the environment, and to be a point of contact for senior people within the business.

But this isn’t the only route communications will come into the project, though it is the most easily described formally. There will also be murmurings and rumours, gossip and chatter, most of which will be of no value, but some of which may actually highlight important issues.

For example, if the murmurs outside of the project, picked up in casual conversations by team members, point at a level of mistrust towards the project (and believe me, this can happen) it is important to make sure your communications out of the project are boosted – the message about the benefits may not be getting out clearly.

Of course, it may be that the project is always going to be seen slightly negatively – sometimes the project is doing work that is of benefit to the organisation as a whole, but not to certain individuals within it. In that case, it’s important to note the problems being aired, and realise they are issues to be dealt with, or indicate risks to consider, as the project continues its work.

Project communications are an important, and often overlooked, part of every project. I’ll be going into this in more detail next week – I hope you’ll join me then.