A short time ago I wrote about the importance of having a value statement, which is a short statement of the value that a project (or programme or team) is accountable for delivering, and which allows us to measure that value. But in practice it’s often difficult to have a short statement which also describes … Continue reading
Previously I wrote about the importance of having a clear goal, in the form of a value statement. But in practice it’s tempting to confuse a goal with what I call a “strategic assumption”—and we shouldn’t do that. When I ask a project team what their goal is they usually suggest a number of things, … Continue reading
Quality assurance and testing are often confused in the digital world. People often talk about QAs being the people who test, and debate the merits of whether QAs should exist as a role separate to that of developers. But prior to that I find it’s important to distinguish between quality assurance and testing, so here … Continue reading
On too many projects it’s easy to get caught in a debate about if we’ll deliver. There is some fixed point at which we’ll be judged—very likely a specific date—and when that happens we’ll look at what we’ve produced and see whether it matches our pre-defined threshold of “acceptable”. If delivery of “acceptable” is in … Continue reading
Over the last 12 months I’ve worked increasingly with people to create what’s been termed a “value statement” for their various projects and programmes. Value statement isn’t my term (although it’s been used before for similar things [1], [2]) and I like it a lot. A value statement is a very simple statement of the … Continue reading
Last week I saw a presentation from Bjarte Bogsnes of Statoil, at a meeting about Beyond Budgeting, which offers “a management model that is more empowered and adaptive [and] releasing people from the burdens of stifling bureaucracy”. Part of they ethos of Beyond Budgeting is to bring decision-making back to the people who have direct … Continue reading
Some people think agile teams have less responsibility because the plans are looser. In fact the opposite it true. When organisations start their agile journey, there are—inevitably—slips and confusion along the way. One thing that often happens is that the reduced up-front detailed planning leaves those outside a team to think there is “no planning” … Continue reading
Burn-up charts are very powerful—they show progress against reality very clearly. A colleague once told me that his boss much preferred the burn-up charts he saw than the more traditional reports other managers gave him, because the burn-up charts gave him confidence based on hard data, whereas other reports were more vague and had milestones … Continue reading
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
