Enter a search term such as “mobile analytics” or browse our content using the filters above.
That’s not only a poor Scrabble score but we also couldn’t find any results matching
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
Product and service development is all about risk. We take on a range of market, design and technical risks in order to gain rewards – new products, better conversion rates, increased market share, improved margins, etc.
Sometimes, however, the risks win. Projects fail for a whole host of reasons: our aspirations run ahead of the technology; we fail to find a commercially feasible solution to design challenges; our competition beats us to the punch. The list is almost endless.
And too many items on that list are entirely manageable. Poor internal communication. Ill-defined scope. Failure to engage key stakeholders. Unrealistic estimates. The project management literature has been calling out such risks for decades.
We know how to solve these problems. We just don’t do it.
That’s the real failure on many of our projects: we fail to see and manage the basic stuff.
Why? I think many project managers are overwhelmed. There’s too much going on for them to keep on top of everything: their team, the technology, the target customer, the political landscape within their organisation.
It’s all too easy to overlook emerging risks until it’s too late.
That’s where project reviews come in. By bringing in some external perspective, project managers are able to get a better feel for what's really going on. Reviews help them spot risks before they blow up and become unmanageable.
Likewise, reviews help senior managers understand what’s really happening across their development portfolio. With a clear view of every project’s status, they can reallocate resources, adjust budgets, renegotiate deliverables and deadlines, and otherwise act to keep their portfolio on track.
So how do you set up such project reviews? Here are nine factors to keep in mind:
Make reviews the norm. If you only review troubled projects, scheduling a review says, “Your project is in trouble”. Project managers will resist this message.
They’ll also resist the overheads that ad hoc reviews create for their projects. When reviews are a normal part of every project, people will accept and plan for them.
Adjust reviews to fit the project. Review teams can bring a range of expertise: technical, design, market, etc. They can operate in different ways – drilling deep into a project at infrequent, structured “gateway reviews”; tracking trends via a series of regular, lightweight peer reviews.
When you set up a review programme, design it to fit the project’s risk profile, budget, skills, etc.
Set clear objectives. A single review can’t drill deeply into every aspect of a project. If you want broad coverage, then it’ll necessarily be shallow. If you want to go deep, you’ll need to focus on one or two areas.
A good compromise might be to schedule two reviews – one to go broad, then a follow-up to drill into the major risks. Whichever way you go, ensure everyone knows what the objectives are.
Don’t impose overheads. No project team has spare capacity to create special documents or assemble fresh information for a review. If they’re asked to do it, they’ll resist.
Review teams need to learn to work from existing project artefacts, and to impose as little overhead as possible for interviews, etc.
Focus on evidence. It’s easy to have an opinion about project status. The hard part is unravelling all the different opinions to uncover just what is really going on and where the risks lie.
Reviews need to focus on this unravelling, and on gathering solid evidence to back their assessment of project risk.
Manage logistics. People overlook the logistics required to run reviews. Scheduling meetings; booking meeting rooms; setting up security passes; getting access to document repositories – these can all take a lot of time.
Many reviews get bogged down in administrivia before they’ve even started.
Act on findings. Nothing undermines a review programme like the perception that their findings are ignored. Coach your reviewers to focus on actionable findings – what can the project team or executives actually do to reduce project risk?
Encourage project teams to act on these findings. Set up mechanisms to track these actions and measure their impact.
Gather feedback. Reviewers are just as human as project managers – they’ll overlook stuff too. Gather data on the outputs of reviews and the impact of their findings on project outcomes, and hence look for opportunities to improve the review process, skills, etc.
Disseminate lessons learned. Likewise, look for common themes and trends within the review findings – these provide opportunities to improve the way you run projects across the organisation. Review teams can be well placed both to spot these common trends and to spread awareness of them.
Reviews are a great way to bring additional expertise and perspective into your projects. They help teams identify and mitigate issues before they blow up.
This doesn’t happen for free – reviews require time and effort from both reviewers and project teams – but the cost is rarely more than a couple of percent of the total project cost.
That’s well worth spending when you consider the cost of project failures that might otherwise happen.