Over the many years in which I have been involved in or running projects, I have learnt many lessons - from observing where things have or haven’t worked. I would argue that these seven are the most important:
Lesson 1: Appropriate communication
Whether you’re using Kanban, Prince 2™, Scrum or any other project management metholodology, you will need to tell some people what they’re doing, and other what is being done.
These are two very different audiences. You can’t expect senior execs to keep an eye on the Kanban board, nor can you expect team members to work from a high-level weekly report.
Ideally, the project management software you’re using will allow different views on the same data, so you can provide the high-level status update alongside the detailed task tracking.
Giving detailed reports is usually actually quite easy. But generating a high-level report that is meaningful at the same time as being concise will require work. Don’t expect the software to do everything… Sometimes you will need to create a simple dashboard for your project board, like these templates available from TechnoPM.
Lesson 2: A product owner who can make decisions
There are two aspects to this lesson. One is that you need a product owner - someone who owns the vision for the end result of the project, who understands the target “user”, the competition and where things are going in this particular domain.
The product owner is ideally intimately involved with the project - communicating the vision, providing regular and frequent feedback, and giving guidance on where to go next.
This means that they must be empowered to make decisions. There is no point having a product owner if all decisions have to be referred higher up.
The project board’s relationship with the product owner then becomes one of accountability (see lesson 4).
The second is that this person must be empowered to make decisions and provide feedback to suppliers. Once those decisions are made they then feed them back to their project board - who simply ratify them. It should be a very rare occassion when the board overrides decisions. (See lesson 7)
Lesson 3: A project manager who talks the right language(s)
It’s important that the project manager is able to communicate with, and translate for, all the project stakeholders.
They don’t necessarily need to be an expert, but they need to understand the language used.
So, when talking with developers or sys admins, they’ll need to be know about the concepts of version control and load balancing.
When talking with product and marketing, they’ll be talking about stakeholder maps and communications plans.
When talking with accounting, they’ll need to understand the importance of budget profiles and financial year ends.
And when talking with learning designers and solutions architects, they’ll be having conversations about user experience and integration.
Part of the PM’s role is to ensure that anything that’s going to have an impact on the wider project is communicated across the workstreams, in a language that all can understand.
Lesson 4: Clear accountabilities
In lesson 2, I discussed the role of the product owner, who is accountable to the project board, but is able to make decisions independently.
Knowing who people report to, and are accountable to, is a major factor in successful projects. Confusion over accountabilities can lead to delays, misunderstandings and significant stress!
The main danger to watch for is with the Project Manager. The Prince2™ guidance is very clear in this regard. The PM works for the project board, and not for the supplier. I would argue that this should apply for any project methodology.
If the supplier wants to have their own project manager, that’s fine, and often a very useful point of contact between supplier and client. But don’t blur the lines of accountability by thinking the supplier’s PM is working for the benefit of the customer.
That’s a nice idea, but when there are difficult conversations to be had, about delays or quality, then you need to know that the PM is batting on your behalf.
Lesson 5: Mix and adapt your methodologies
While there are purists who will only use concepts, tools and techniques from Prince2™, Scrum, Kanban, PMI et al, I would recommend that you adapt your methodologies to the context.
Often a mixture of waterfall and agile methods can work well - using waterfall approaches (project boards, Gantt charts, phase boundaries, project initiation documents, RAID logs) for the big picture, whilst, adopting agile concepts (sprints, scrum stand-ups, show & tells) to manage the smaller elements. Some element of iteration within a larger plan often works very well.
For a single, exclusive methodology to work well requires everyone on the team - customer and supplier - to be signed up to and fully understanding that methodology. This is why many agile development companies request that their customers get some sort of agile certification before they start their projects.
Precisely how you adapt your methodologies will depend on a number of factors:
- Project size (or how much it can be broken down)
- Customer experience
- Supplier experience
- How well the project scope is understood
- Whether this is a one-off, or whether there’s scope for continuous, iterative improvement
Lesson 6: Ring fence your project team
Project teams need time away from their Business As Usual work to focus on the project.
Anything that comes in from their BAU life that’s likely to have an impact on the project needs to be treated and managed as a risk (if it’s not yet happened) or an issue (if it’s happened).
Just don’t ignore the potential for BAU to scupper a project!
Lesson 7: Avoid management by committee
This links to lessons 2 and 4. If you have clear accountabilities and decision-making vested in individuals, then projects can be made to run very smoothly.
If, however, decisions come back to large groups of people, expect to significantly increase the time required for those decisions to be made.
This is most often seen in content development projects where sign-off is required from various stakeholders: communications, subject matter experts, legal, operations etc - and often the stakeholders’ line managers too.
The worst we’ve seen (for a nationally rolled out high stakes project) is a review panel of more than 20 people, most of whom had very little contact with the project on a daily basis. The best (for a similar sized project) was a review panel of one person - closely attached to the project, who then “sold” his decision to his project board.
Guess which project went most smoothly?
Posted: 21 April 2016
Tags: System implementation Project management