Recently, I was asked how I would lead a large, complex project.
Three key principles emerged from the conversation:
- Communication is critical
- Know your stakeholders
- Build in flexibility within defined boundaries
Communication is critical
Projects fail when people don’t talk to each other, when tasks and issues fall through the cracks, and when there’s no clear understanding of who is doing what, by when.
As always, project communication is more of an art than a science. But I’ve found that there are some useful, practical ways of helping ensure people are kept up to speed:
- The frequency of status update reports and project meetings should match the speed of change in the project. The more that’s changing, the more frequently you will need to communicate.
- Keep status updates and meetings short! 30 minutes maximum, 10 minutes is ideal. If a discussion needs a longer time, or an in depth document, then deal with it separately, with just the right people involved.
- When you send out a project plan update, provide a summary of the changes that have been made – especially when there have been structural changes to the tasks.
Know your stakeholders
The first task of any project manager should be to identify who needs to be satisfied, managed, informed and monitored as the project proceeds.
As you start to talk to the people around you, the list of potential stakeholders will grow, and you’ll need to prioritise which ones you spend most time on. That’s where a Power/Interest Grid comes in useful.
As you come across people, understand their motivations, their interest and the levels of influence they have, mark them on the grid which will then indicate how you might need to manage them (or not).
For more information on Stakeholder Management, see Mindtools > Stakeholder Analysis
Build in flexibility within defined boundaries
It helps projects greatly if there is a shared and explicit understanding of what is to be achieved by the end of the project. This sets the scope of the project and should be recorded along with any constraints that you’re working within. Keeping the scope small for each phase will normally help the project to run well.
How those end results get achieved is another matter. In an ideal world, all the decisions would be made up front, and then the delivery team just delivers against those decisions. In the real world, I don’t know all the answers at the beginning. Often I don’t even know all the questions.
So, the process becomes like a funnel. At the top (the beginning), you have a lot of flexibility to make changes. Decisions will be made at this stage about things like the software to be used. You’ll be looking for decisions that allow you further flexibility down the line. Some decisions will result in revisiting earlier changes, in an iterative process – but all the while keeping an eye on the end result, and not allowing the scope to creep.
You’ll also be looking for ways to keep the project as modular as possible. Not just the software but also the tasks and the processes being designed. By modular, I mean trying to avoid dependencies as much as possible. This, again, allows for flexibility and change as the project progresses.
As you go further down the funnel, towards an end product, the scope for change decreases. When a change is requested at this stage it will a careful analysis of its impact on other parts of the project. Sometimes even the smallest change, like a phone number, can have massive impact. So you’ll need to make sure you understand the relationships between the different components of the project, and have a process for managing change.
Posted: 22 April 2013
Tags: System implementation