8 basic areas for project kick-off

I’m a big fan of Agile thinking, so I’m also a big fan of up-front thinking – as long as it’s light-touch and rigorous. Up-front and Agile? Yep. This is to avoid the scenario in which the dev team and the business are inseparable in their mutual respect and shared desire (hurray!) to deliver value for money (great!) while using all the leanest, extremest, scrummiest tools and techniques (cool!)… only to go in circles (aargh) because no-one dared commit to some fundamental principles up front (doh).

Ultimately this is about customers, users and suppliers understanding (before coding begins) why the business is investing, how value-for-money will be understood, who’ll be doing what, how much is expected about what the products will look like, who’ll be affected by those products, how much flexibility there is around time-scales, who needs to be kept informed of what, who gets it in the neck if delivery fails to meet expectations, and who’s going to run the products once they’re released.

This is a collection of highly relevant facts that would in most cases fit on the back of an envelope. Little or no analysis is involved, just some leg-work and a bit of thought about what we’re trying to achieve and the approach we’re going to take, and writing up what’s been agreed.

There is nothing predictive about the facts being collected, they simply summarise what is understood before work commences.

This upfront work should take as little effort (provide as little detail) as possible to be effective, and as much effort (provide as much detail) as necessary to be effective. The person responsible for kick-off needs to judge what level of detail is right in proportion to the investment.

I think project kick-off should consider eight basic areas:

1. (Re)State the business case: the reason we are going to create the products. The Business case should state:

• The business needs or opportunities that the project’s products are intended to meet
• The investment rationale (what would constitute value for money; in some cases this might be stated in very broad terms).
• Key risks and dependencies

2. Establish user categories and their respective needs (high-level user requirements and constraints) and agree how user interests will be represented throughout the project lifecycle. The emphasis here is on establishing who are the relevant users beyond the obvious categories of the business and the end user.

3. Establish the business’ attitude towards time, cost and product (scope/spec/bells&whistles/gold-plating/performance). This might be expressed as priorities and/or as tolerances and might include a possible release schedule (either relative or absolute dates).

4. Outline the product(s) that is/are expected to meet user needs. At this point it could be as hi-level as “bridge, or boat?”, or might be more granular. This might have been sufficiently covered by point 3, above.

5. Agree a framework that ensures development proceeds and continues with the customer’s informed consent to spend. The customer and the project team need a shared view of how the investment can be most effectively planned and monitored. What effort should be spent now to estimate what? With what level of certainty? What effort should be spent throughout the project to estimate what, at what milestones, with what level of certainty? What effort should be spent throughout the project assessing the impact that emerging knowledge has on time, cost and product?

6. Establish how the project will be organised. The basis for project organisation should be ensuring certain key areas are each allocated an accountable owner. I’m currently in favour of nine “key areas” that I think are essential to most design and build projects, though I can imagine variations on this that would be just as effective or possibly more effective. I’ll provide more detail on the nine “key areas” in a future post.

7. Outline how project and product status will be communicated. This might be sufficiently covered by project organisation.

8. Outline provision for running/supporting products from first live release.

Kick-off might also include:

• Outlining the practices expected to be used by design & build team(s). This might have been adequately covered by organisation and communication.
• Refinement of the business case in light of lessons learned while compiling kick-off information.

The nature of the project will determine how much effort is required to complete project kick-off.

Project kick-off is actually nothing more than a check-list: before design and build begins there are these basic areas that should have been thought through, and the outcome should have been compiled in a project kick-off document.

The project kick-off document sets out what is known and agreed at the beginning of the project.

It has no role in dictating how the project will then unfold and evolve.

Whether or how the document will be revised and baselined to reflect ongoing evolution is for the business owner to decide.

More on this in my subsequent post, Up-front Analysis – the Agile way!

Advertisement