Tag Archives: scope and requirements

Project scope and/or requirements

Benefits Map: Impact Mapping for Programme Managers

Posted on by

Gojko Adzic has recently published a great book on a technique he calls “Impact Mapping”. Gojko’s Impact Maps are a visualisation of the business drivers and the associated project scope. This means the people doing the work (developers, UX, testers, etc) know what to build but also why they are building the functionality, how the functionality fulfils the business outcome and and who the functionality is for. Love it.

As it happens Programme Managers already have a very similar tool for a similar purpose. Benefits Maps, like Impact Maps, are used to visualise business drivers and associated scope, in this case programme scope. They answer two key questions:

  • Why are we doing the programme?
  • How will we realise the benefits?

The dual function – showing why and how – make Benefits Map high value documents. It also means a Benefits Map can easily morph into the initial Programme Blueprint. For a simple programme the Benefits Map may be the only Blueprint. And the diagram format means it fits on one page. Even in a world where we value “Working software over comprehensive documentation” that one page is worth having.
Continue reading →

A Clear Vision is Essential for Agile Programme Management

Posted on by

Search the Lean-Agile literature and you’ll struggle to find much mention of vision. Agile is all about short planning horizons, releasing stuff early and often, and learning. And a vision doesn’t necessarily help with that.

My direction? Anywhere. Because one is always nearer by not keeping still

The quote is from Engleby by Sebastian Faulks (cited Good Reads) and pretty much sums up the Agile attitude. Movement is the key rather than the direction of movement. Most Agile initiatives (i.e. projects and product development) are simply about building high priority stuff now, so it is no wonder that the Lean-Agile methods are relatively silent about the future.

In contrast a programme is about organisation change and the vision helps define the future state and attract buy-in – it is a “Postcard from the future”. A clear vision is an essential mechanism for staying aligned with business strategy. Alignment is, of course, one of my three threads within Agile Programme Management. The vision should be stable; not static but broadly resistant to change. Despite Agilists desire to “Embrace Change” a radically changing vision suggests the programme is no longer aligned with strategy and hence raises the question of whether the programme should be shut down.
Continue reading →

Revisiting the Iterative Incremental Mona Lisa

Posted on by

In his brilliant post Don’t know what I want, but I know how to get it Jeff Patton used a sketch of Mona Lisa to illustrate the difference between Iterative and Incremental development.

Jeff points out that many Agile people use the word “Incremental” when they mean “Iterative”. I believe this is because, in reality, most Agile projects combine both approaches and become Iterative Incremental. In fact I can’t imagine delivering software in any other way.

To illustrate what Iterative Incremental means I’ve taken Jeff’s Mona Lisa illustrations and added a third showing a combined Iterative Incremental approach.
Continue reading →

Reinforcing Success in Products and Projects

Posted on by

A fundamental military axiom is to reinforce success.

Reinforcing success is a strategic concept used in many areas of decision making and management. Originally a military doctrine, the term is also used in theories related to parenting, business and other fields. It is essentially a selection criterion, or a prioritizing principle. A course of action is selected from various options on the basis of previous results of similar actions. The basic idea is: if it works, keep doing it; if it doesn’t, don’t invest more in something that’s failing.

Wikipedia: Reinforcing Success

I believe businesses should apply this principle to projects, products and product features. So not surprisingly I apply this as a guiding principle in my own work as an agile programme manager.
Continue reading →

Requirements: State the Problem not the Solution

Posted on by

We all do it. Even those of us, like myself, who should know better do it occasionally. But it is wrong. Or if "wrong" is too strong a word, then it is at least misguided.

What is it? It is the habit of stating a solution when we should be explaining the problem. This habit isn’t confined to a specific role; I’ve seen all members of the team do this … users, product managers, project managers, business analysts, technical architects, developers, user experience designers, testers, and management stakeholders.
Continue reading →

Change is Good for Agile Projects

Posted on by

Kelley Hunsberger interviewed me for her article “Change is Good: For agile projects, redefining scope isn’t such a creepy thing”. It is great to see agile thinking in a mainstream project management magazine such as PM Network. And the article was a very nice little summary of why it is good to embrace change.

I took the opportunity to reiterate some of the points I’ve already made on Agile Project Scope and Agile Change Management, namely that all projects experience changing requirements and it is better to embrace this than fight it. For example legitimate sources of change include:

  • The customer learns as they see working functionality emerging of the development effort.
  • The technical team is also learning as they discover what works.
  • The environmental context might also dictate changes, such as changes in the market or legislation.

Ignoring any of these sources of “scope creep” would be foolish.
Continue reading →