Tag Archives: project initiation

Project Initiation

Programme Organisation for Software Delivery

Posted on by
Reply

I thought I’d share the way I organise programme teams. I’m interested in software delivery so I’m talking about programmes that have software development at the core. Non-software programmes would have a different structure and mix of roles. I push Agile but the same organisation would work with a less nimble approach.

There is nothing mysterious or radical about my programme organisation. In fact it is entirely in keeping with the guidance from Managing Successful Programmes (MSP). If you didn’t know Organisation is one of the nine Governance Themes from MSP.

Although I tend to apply the same shape to all of my programmes I do adapt it to local conditions. The size of the team makes a big difference so I’ll show how I have organised large, medium sized and small programme teams. I’ll also take a quick look at a poor structure for a programme team – with role based teams – and explain why I don’t fancy it.

There are obviously other ways of structuring a programme team but this is what has worked for me.
Continue reading →

Benefits Map: Impact Mapping for Programme Managers

Posted on by
Reply

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
Reply

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 →

Reinforcing Success in Products and Projects

Posted on by
Reply

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 →

Two Types of Post Implementation Review

Posted on by
1

Recently people at work have been asking my advice on how to run post implementation reviews of major programmes so I thought I’d write up my thoughts. I believe there are two types of post implementation review and I recommend doing both. The first type happens in Project Closure and the second happens after the project has finished, i.e. Post Project.
Continue reading →

Agile Project Execution

Posted on by
Reply

Executing is one of the five project management process groups in the Project Management Body of Knowledge (PMBOK) from the Project Management Institute (2004).

Project Execution is where you build the project deliverables and hand them over to your customer, i.e. where you build and deliver the software. This is where most of the project effort is invested. Agile Project Planning says what you intend to do, when, and Agile Monitoring & Control helps you stay on track but Agile Project Execution is where you do the business.
Continue reading →

Agile Roles and Responsibilities

Posted on by
2

Each of the Agile methods includes defined roles.  Some have more, some have, less.  DSDM is the only one of the methods that makes a big deal of making role responsibilities explicit but I think this is important. To work effectively as a team people need to know what their role is and the roles of their peers. I have often had to coach teams on the demarcation between key roles on the team – typically the leadership roles, i.e. project owner, agile project manager (or scrum master) and technical lead.
Continue reading →

Agile Project Planning

Posted on by
1

No battle plan survives contact with the enemy

Plans are nothing, but planning is everything

Field Marshal Helmuth Graf von Moltke

I believe that Agile Project Management provides certainty of delivery. Planning is what lets us answer the question “When will you be finished?”. Planning is, however, just the start of the process. As Moltke pointed out planning is more important that the plan because once you start the project you’ll find the plan is wrong and you have to adapt. All plans need revisiting and you will have to use Agile Project Control, Agile Change Management, and Agile Risk Management to get the promised certainty of delivery.
Continue reading →

Agile Pre-project

Posted on by
Reply

Agile Lifecycle Pre-Project

There are some important questions to be addressed before the start of any project like “Why are we doing this project?” and “Should we do this project?” Project Initiation is the phase where these questions are answered but some work has usually been done before.

Find/Write Project Brief

Projects don’t happen in isolation. The key question during project initiation is “Should we invest more?”, i.e. is the project worth going ahead with?  There must be a reason for the project. The first step during Agile Project Initiation is to find this reason. Often with software development there are just too many choices for what the team could do. A Project Brief can help remove this confusion by pointing the general direction in which the team is meant to head.

The format of a Project Brief document might be a Project Vision, in part of a Product Road Map or a Project Mission Statement but the key thing is knowing why we’re spending this money on this activity.

Marty Cagan of the Silicon Valley Product Group suggests we provide good answers to nine questions to know if we are pursing a good opportunity. The nine questions of the Opportunity Assessment are:

  1. Exactly what problem will this solve? (value proposition)
  2. For whom do we solve that problem? (target market)
  3. How will we measure success? (business metrics)
  4. What alternatives are out there? (competitive landscape)
  5. Why we are best suited to pursue this? (our differentiator)
  6. Why now? (market window)
  7. How will we deploy this? (gentle deployment strategy)
  8. What is the preliminary estimated cost? (small/medium/large)
  9. What factors are critical to success? (solution requirements)

I encourage Product Owners to answer these questions before launching the project proper.

High Fidelity Prototype

The Silicon Valley Product Group recommend a a High Fidelity Prototype rather than using documents to describe the target system.  If the Project Brief gets the go ahead then invest some time in putting together a click through prototype of the system.

References

Silicon Valley Product Group