Main elements of a project

Introduction

These guidelines are well established and can be found on many "how to do it" websites. They have existed in the business world since the 1950s without major change, except for the introduction of an "agile project" approach around 20 years ago. They apply to XR but need adapting to take account of its principles and values, because deadlines cannot be demanded and teams may choose not to follow them.

Having a consistent way of running projects means :

1. projects will more easily and more likely be completed on schedule, within budget and comply with what was proposed in the first place,
2. people know what to expect to see in a proposal and a project plan,
3. members of new teams can work together easily because they use the same, familiar processes,
4. people realise that so many tasks are really projects needing to be managed than they ever thought. Even a visit to a supermarket needs a plan, a shopping list, contingency items, a budget and resources to get there and back. You could even run a risk assessment on the weather forecast to see if an umbrella is needed.
5. there is less pressure on members of a project because their responsibilities are clear.

The Systems Realignment project recommended an external project team be used to oversee progress and support all projects.

Project Proposal

TBA, but will summarise many of the elements of a Project Spec.

Project Specification

The following elements should be described in a project specification. For a small project, some can be omitted. The full list is :

1. Vision - what will things look like when the project has completed successfully?

2. Objectives of the project - why are we doing this? Same as Goals.Are they realistic, clear and measurable?

3. Stakeholders - who has an interest in this project?

4. Deliverables - what are the products and results of the project?

5. Team members, their roles and responsibilities. Essential is a roject manager who is accountable for the success of the project.

6. Plans - phases and tasks within each phase

The project spec should be agreed by the main stakeholders. Then create a PID (Project Initiation Document), but this is not needed for a small project.

Project Initiation Document (only for large projects)

1. State the need and justification.

2. Decide how to run project meetings to review progress, how progress will be recorded and how problems and issues are managed.

3. Stakeholders - those with an interest in the success of the project.

4. Hold a kick off meeting so those in the project know what to do and why.

5. Create a risk register, agree who is accountable for it and at what intervals will it be reviewed (typically monthly). See Risk MAnagement.

Project Planning

Without a plan, a project drifts, no-one has an incentive or accountability to complete a task and no-one will know by when a task should be completed.

A project may be a "waterfall project" or "agile project". A waterfall is a traditional, sequential set of tasks best used when the objectives are clear. An agile project is where the end result is not yet clear and comprises a series of "sprints" each of which delivers some benefit. At the end of each sprint, hold a review and agree the purpose of the next sprint. Cynically this can be seen as "making it up as you go along" but it must still be properly planned.

Waterfall project

1. Project phases : high level, identifiable sub-projects each of which delivers some benefit. Not needed for small projects. Without phases, the project will drift without delivering anything until the very end, by which time key members may have left and others forgotten what it was all about.

2. Project plan : a list of tasks within each phase, who is accountable for each, their start date, completion date, dependencies between tasks. A plan can conveniently be shown on a Gannt chart, which is a series of timelines, 1 for each task and easily constructed using a spreadsheet.

3. Progress meetings : these enable the status of each task to be tracked and reported. A common and simple approach is to assign a RAG status to each task. If a task or phase is Green, then it is on track in 3 ways :

1. on schedule,

2. within budget,

3. able to deliver what was specified.

If Amber, then it is in danger of not complying, if Red it will fail on 1 or more of those 3 criteria. The project team must take steps to move Red tasks to Amber and Amber tasks to Green, by changing the schedue, budget or specification.

Agile project

In effect, this is a series of phases which are still controlled as for a waterfall, ending when the project reaches a point of diminishing returns and further effort is not effective.