Reviewing a project initiation

I was recently asked to help a client kick-off development of a new product. This was to be their first “agile” project so the kick-off had to set the scene for the collaborative development approach that was to follow.

I used a variety of tools and techniques to bring the project to life. As is usually the case, some worked better than others so I thought I’d review the approach and describe some of the issues and possible reasons.

The agenda for the day was:

  1. Review project vision and goals
  2. Establish key priorities and concerns
  3. Establish candidate releasable chunks
  4. Decide what to do first

Attendees included the development team, development management and business sponsors.

Project Vision

After some general discussion about the product we set about defining the Vision. The group were split into smaller groups each mixing development and business folk. Each team was asked to come up with an elevator pitch for the project of the form:

For __Customer__ who __has some need__
the __product name__ is a __product type__
that __will provide some benefit__
unlike __competing products__
out product will __key differentiator__.

In reviewing each groups proposed vision statement we settled on a single elevator pitch that embodied the purpose of the project and began to focus the team on what might be important.

Project goals

To further cement the way in which the product could be judged a success we went on to identify candidate goals. These included some consideration of how we might measure success.

These two exercises were received with some enthusiasm as the sub teams collaborated over achieving an accurate representation of the product. The need to measure outcomes causes business sponsors to work with those who were more technically minded in order to achieve measures that were specific, measurable and representative of the desired outcome.

Goals in this example included areas such as customer and sales force satisfaction as well as specific operational cost reduction goals.


This is a technique that I picked up from Rob Thomsett’s Radical Project Management. I have used it to great effect in the past where trade-off was a critical demand of the project.

The sliders technique works by selecting a set of traits that could be considered to be in tension. These are represented as sliders that can be fully on, fully off or anywhere in-between. The stakeholders and team can discuss the implications of various slider positions. For example when considering cost and budget to be fixed we may choose to allow for some flexibility in scope in order to ensure quality.

Thomsett uses these seven measures of success; satisfied stakeholders, meet requirements, meet agreed budget, deliver on time, meet quality requirements, satisfy the team. I have used the same technique with other measures such as maintainability, time to market etc.

This technique was less well received than the previous two. While the discussion that was provoked was valuable some members of the group were unhappy with the somewhat arbitrary nature of the measures. One sponsor suggested that he felt that he was having to trade off his goals before even the project has started.

I believe that this early trade-off is a valid concern and it came up more than a couple of times throughout the project. When we apply agile principles to product development we look for small meaningful increments. This can be uncomfortable where a sponsor has internalised a grand vision.

Establishing releasable chunks

This exercise starts with the suggestion that it is good for the project to reach a releasable state early. We begin by identifying a set of capabilities of the system. These are grouped based on cohesion. I use the notion of Minimal Marketable Features to focus on achieving small releasable increments. We begin to prioritise these and work to make the first chunk as small as is reasonable in order to achieve marketability.

This was the most valuable and effective part of the day. The notion of MMF was used extensively through the project with the business sponsor often stating that a feature was “important but not necessary for this MMF”. Further, the focus on marketability places some focus on needs that can often be deferred such as security testing, performance testing and help facilities.

The following day would include beginning to identify the User Stories that would be necessary in order to achieve MMF 1.

Lessons learnt

In reflecting on this exercise there are things I would do the same and things I would consider doing differently. The initial Vision and Goals exercise was well worth while. While I know that the success sliders approach can be useful I may not have used that technique in this particular context.

A technique that I chose not to use, on reflection, would have been a good choice. As a part of the identification of releasable chunks we should have begun to identify those personas that we could address and how they related to different feature sets. I believe that this would have increased our focus on specific features and aspects of features.

We live and learn :)

Thanks for taking part in my mini retrospective on this workshop, I hope it can be of use to others. Please do feel free to ask questions of make comments below.

Technorati Tags:

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>