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 »

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.)

Working in IT project management, I’ve had a lot of experience in building interfaces as part of my projects. But the important ones are nothing to do with the technology.

When you are working on an IT project, it can be too easy to get carried away with the technical possibilities. I have worked with many excellent technical staff, some of whom are more interested in seeing how far they can push the technology than in ‘just’ hitting the requirements.

Often they find it difficult to explain how the new possibilities the technology opens up could be applied in the business. Sometimes they don’t know – your technical staff will not know everything the business needs to do. Sometimes it’s because they aren’t able to explain it in terms that the rest of the business understands.

This is where you as a project manager can help. As well as running the project, you are also a major link between the project and the external environment. You are, in fact, an interface between what is going on inside, and what is going on outside.

For many of the projects I have worked on, an important part of my role has been to explain the technical process to others, and in turn explain business requirements back into technical steps that need to be taken.

The only way to do this is through listening – listening to what your technical team is telling you, and listening to what the business, or non-technical members of the team, are telling you. Only by listening can you find out both what is possible, and what is needed.

Interfaces aren’t dumb devices that just parrot what one side says to the other. They also need to do some conversion, some translation, to make sure both sides understand each other clearly.

So remember, listen carefully, understand what is being said, and make sure you help others understand too.

We all want to have successful projects. But what do we mean by successful? It’s not just a matter of hitting our milestones, on time and on budget. It’s also about making sure that the project goals are of value to the organisation we are working for.

At the start of every project, you will produce, or help produce, a document that sets out what success looks like, the business case. That means you need to be able to examine the situation the organisation is in, and identify what problem the project will solve.

But this work doesn’t just stop there – while you may be working away on your project just fine, there will be other things happening in the world! It’s important that you remember to revisit the business case often, to check that the project is still meeting a need.

Remember, a project that is managed perfectly won’t necessarily be a success. Don’t forget to look up now and then, and take a look at the wider picture. A successful project isn’t about perfect documentation, it’s about delivering something that benefits your organisation.

I’m pleased to announce the release of my audio lecture course, “Understanding Project Management”. The course is designed to help give newcomers to project management a solid foundation. It covers all the essential concepts and techniques you will need, and help get you started on your project management journey.

You will also learn about some of the common pitfalls you will face – and how to deal with nay-sayers in your own organisation!

You will learn:

• to begin a project – defining what you want to achieve
• to get to where you want to be – planning
• to recognise when problems are coming – and how to deal with them
• to deal with risks by spotting them early, and taking the right action then – not when it is too late
• to review your project regularly – recognise where you are, what you have achieved, and what there is to do

As well as the 11 lectures, the course also includes project management document templates, enabling you to get up and running quickly. As a special offer at launch, there is currently 20% off the list price – don’t delay, this will only last until the end of next week!

For more information visit the Understanding Project Management site, or go straight to the order page.

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 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.