A project lead once told me that there is no point in planning as ‘plans always change’. The project dived straight into the implementation phase and missed out key parts of the project lifecycle. You won’t get a prize for guessing it failed.
I set up projects to succeed.
This is a brave activity. It means investing in the front end of the project and seeing little ‘progress’ for a while. However, it puts your projects on the right footing. You don’t need rocket science to build a good project. Just a few simple actions, within a project lifecycle, can differentiate successful projects from those that waste time and money, and destroy credibility.
- Understand what you want and agree with stakeholders
- – This might sound beyond obvious but most projects that fail do so because the project team does not understand the requirements of users and stakeholders
- Set up governance
- – Regular milestones reviewed by all stakeholders keep the project on track and give you a ready-made set of supporters when things change
- Understand what you need to do, how long it will take and what it will cost
- – A really good, full business case* reduces change later in the project
- – Two-way communications smooth the change curve and bring intelligence into the project
- Manage risk
- – It is never too soon to manage risk. Never.
Good projects follow a project lifecycle** to make sure we dig the foundations before building the roof
- The five points above are part of the CONCEPT phase. In this phase and all others, a good project manager recruits and listens to their team. Together they carry out and document these activities.
- Next, the team start to DEFINE the project – you can call this detailed planning. This is where you get the Gantt chart. But you should expect so many, much more useful things. Like work scopes, risk management (though I hit this hard in the concept phase) and bought off requirements. I am open to starting delivery activities in the definition phase. Earlier, if there is a clear case.
- Then we get on with the job of DELIVERY. For the project manager, this can mean anything and everything from supporting the team, updating stakeholders, clearing the path of obstacles and hazards, and reporting progress. You may have heard the term ‘Monitor and Control’; I prefer ‘Report and Support’.
- Finally, we HAND OVER to a Business As Usual team. This is our legacy. We make sure the customer is happy and CLOSEOUT the project. We collate, assess and report lessons learnt. And we make sure our data is properly archived so that others can pick up and use our work if necessary. For instance, having the work scope and the actual times and costs makes estimating the next project a lot easier and more accurate.
Working within the project lifecycle
As a Project Manager, I work with the project team to understand how we can succeed. I listen to and challenge team members to plan the best outcome for everyone in the organisation. I anticipate risks and issues and make sure we know how to tackle them. I keep activities on track and plan for benefits delivery. Be that closing down a server or growing turnover.
I quickly get to understand an organisation, its goals, capabilities and constraints. I work well blending the big picture and essential detail. Strategic thinking ensures my projects meet business goals and deliver benefits. Managing the details safeguards the solution by reducing risk during implementation and addressing the needs of all stakeholders.
Regardless of the size of the project, these steps will help you Plan to Succeed. Sometimes they take a few minutes, sometimes they take longer and need more formality. I can help with any scale of activity.
*I am a member of the UK’s only chartered body for the project profession – the APM – we use business case in a very broad sense. You may be more comfortable with the term Project Initiation Document (PID). As you will see from this post Project frameworks – the secret of your success, they are pretty much the same thing.
*This section describes the project lifecycle defined in the APM Body of Knowledge. Complex solutions often need more stages within one or more phases of the lifecycle. For example, product development projects may have sub-stages within the design and build stages of the implementation phase. Programmes and Portfolios demand more complex lifecycles.