Recently I’ve been exploring a few online tools to use to assist with project management. One of those I’ve found particularly useful is Trello.

Trello is essentially an online version of a Kanban board. Like a Kanban board, it has multiple columns in each board, so that tasks can be created on the left hand side, and moved from column to column as the tasks are processed.

Obviously the most common use of Kanban is in software management, so development tasks, or user stories, would move through to development, testing, implementation, etc. However, these are not the only projects that can take advantage of this particular technique.

The replication of the usual physical Kanban board in a digital manner has some clear advantages. Teams which are not physically located in the same space can share the same board, and still be able to manipulate it in real time. Tasks can be assigned to particular people, and re-assigned simply. Extensive notes can also be appended to tasks, which in the real world would probably just make them fall off the board…

Security and privacy can be a concern when moving to using an online solution, particularly when the solution is hosted elsewhere. Trello allows you to create boards which only members of your organisation can see, and even to restrict access to named people. In addition, it is simple to allow certain people from outside of your organisation to use the boards, which has clear uses when it comes to projects across organisations.

The final advantage, of course, is that Trello is a free service. Take a look, and let me know what you think!

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 »

I needed to do a quick ten-minute presentation recently about the factors needed for successful projects. This is what I came up with – let me know what you think! What are your ideas?

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

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.

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.

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!

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.