Of all the GDS governance principles for service delivery, the one I probably repeat most often is “Trust and verify”. As written it’s directed at managers—it’s to ensure they give the team more freedom (“trust”), but to also to let them know they can still have some assurance (“verify”). Yet despite the positioning towards managers … Continue reading
A common distinction made between projects and programmes is that projects deliver outputs (things) whereas programmes deliver outcomes (benefits). I think this is a dangerous separation, particularly in digital projects and programmes today. The view is most evident in the Managing Successful Programmes (MSP) approach, which has been long advocated by the UK government. But … Continue reading
Do you practise good Benefits Management? It seems like a heavyweight process, with a lot of bureaucracy, especially as I’ve chosen to capitalise the initial letters. But it need not be so heavyweight. A short time ago I saw a presentation on Benefits Management and it certainly came across as heavyweight. A statement was made … Continue reading
I often come across the call for consistency… it sounds sensible, but can often be more damaging than people expect. Here I am talking about enforcing consistency across teams, projects, departments, etc. It might be about using the same user-story tracking tool, having different teams’ iterations in sync, reporting project progress using a standard template, … Continue reading
Where do you list your project risks? The more traditional project management approach tells us to use a risk register, and that’s certainly what happens in a lot of projects. But from my point of view it’s a trick question, and that’s not just because “risks” are not singular. We might write some so-called risks … Continue reading
Having objective measures enables better focus. Here is an example at the governance level. I once helped a project add some objective measures to its reporting. They previously had a list of things they wanted to build, but until that point the project’s goals hadn’t been expressed very clearly in terms of what the outcomes … Continue reading
One of the most problematic situations that a delivery team can find itself in is when its stakeholders have expectations of a fixed deliverable by a fixed date. Generally speaking if a technical project ties itself to a pass/fail situation then it will fail. This is by no means true all the time, but it’s … Continue reading
People don’t measure the impact of their work nearly as much as they should. As an industry we’re pretty good at measuring our outputs—the stuff we produce—such as features, story points, and so on. But we’re not so good at measuring the outcomes—the value of what we produce. I think a lot of that is … Continue reading
One effective way to make delivery smoother is to integrate “gatekeeper” stakeholders into the development process. This is particularly valuable for large projects in large organisations. In small projects life is much easier. It’s relatively straightforward to get all your stakeholders to a stand-up meeting or demo, make sure they’re happy, and be sure that … Continue reading
A test of whether we are getting the most out of agile is whether we can get partial value from partial delivery. Often I hear people in delivery teams say “We’re doing well at agile, but we’re being held back because the rest of the business needs to be agile, too.” In many ways I … Continue reading
