One company I worked with called the start of the project the “Blueprint” as it is about roughly shaping the project and product. “Inception” is another common term for this phase in agile projects. This article outlines traditional project initiation then delves into more detail on Agile Project Initiation.

Traditional Project Initiation

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

In the UK project initiation usually means writing a Prince2 style Project Initiation Document (PID) or the equivalent.  Once you have the PID the Requirements Capture, Analysis and Design activity can begin.  All of which is rather time consuming.

The Project Initiation Document (PID)

The defining feature of the Prince2 Project Management method is the PID. It can take a considerable amount of effort to write this document. OGC: Project Initiation Document (PID) gives the suggested content:

• As a minimum the document should answer the following fundamental questions about the project:
• What the project is aiming to achieve
• Why it is important to achieve it
• Who will be involved in managing the process and what are their responsibilities
• How and when the project will be undertaken
• The PID has to answer the above questions to a sufficient level of detail to maintain control of the project. The document should cover the following areas:
• Background, explaining the context of the project, and how we have arrived at the current position of requiring a project.
• Project Definition, explaining what the project needs to achieve. Under this heading will be:
  • project objectives
  • defined method of approach
  • project scope what is included and what not
  • project deliverables and/or desired outcomes
  • exclusions
  • constraints
  • interfaces
  • assumptions
• Project organisation structure, detailing who is going to be involved and what their responsibilities are (team management structure and job descriptions)
• Communication plan, describes how the project stakeholders will be kept informed during the project
• Project quality plan
• Project controls, laying down how control is to be exercised within the project, and the reporting and monitoring mechanisms that will support this
• Business case, covering the estimated costs, risks and benefits. The Business Case will require regular review throughout the project and may require updating
• Initial project plan. The plan will be reviewed and further developed at regular intervals during the project
• Risk register containing details of the identified risks so far. The Risk Register will be reviewed at regular points during the project to assess progress on managing risks and to identify new risks that may have appeared

Requirements Capture, Analysis and Design

These phases are all about identifying the requirements and then transforming them into a format suitable to hand to developers.  The Requirements (see Project Scope) are usually in business language.  Analysis, usually done by a systems or business analyst, extracts the logical requirements.  Design attempts to show how the logical requirements which be met technically.  These phases are all time consuming, happen in sequence, and involve different people at each stage.

Agile Project Initiation

The Agile methods are beginning to acknowledge that some upfront work is required to ensure project success. Project Initiation includes all the work necessary before full scale coding begins.

Agile Project Initiation includes these steps:

1. Find/Write Project Brief
2. Form the team
3. Initial Plan
4. Initial Requirements
5. Initial Infrastructure

The difference between Project Initiation and the equivalent in a traditional waterfall process is that Project Initiation is time boxed and the Agile Team do the work.  a couple of days is all you need for a small project and a month is fine for a large project. Given the short time period the initial deliverables will not be perfect but perfection is not the aim. The idea is to do barely sufficient work to begin developing a solution. For some deliverables, e.g. Release Plan and Risks and Issues Log, these will be only the first version of many created during the project.

For further information on activities to include in Project Initiation, check out the Business Study in DSDM (2002) and Iteration Zero in XP (Beck 2000).

Find/Write Project Brief

Strictly speaking the Project Brief should exist before the project but in reality this often hasn’t been done and the Agile Project Manager should to write/find it.

See Agile Pre-Project

Form the Team

The Agile Project Manager mobilises the Agile Team and ensures the Agile Team has an appropriate work space and support.

An Agile Team should contain the mix of skills required to deliver the product. Common skills are Project Managers, Product Owner, Designers, Developers and Testers.

Agile promotes close collaboration between team members so advocates co-location of the team members. Co-location makes for better channels of communication and counters Conways Law which suggests poor channels of communication may be reflected in the structure of the end product (Wikipedia: Conway’s Law). If the team have a dedicated work area then they can use their workspace to display visible progress towards their Timebox Goal.

This is a good opportunity to do the following.

• Identify and arrange any necessary training
• Set up recurring meetings and book rooms for Timebox Planning, Demos (also book a projector) and Retrospectives
• Arrange for the team to sit together
• Order a board if you need one
• Prepare for the first Timebox planning ( See: Timebox Pre-Planning)
• Create a project space and decorating it with material, staking it as the informative workspace as defined in the Agile glossary.

See Agile Roles and Responsibilities

Initial Plan

The Release Plan is a reflection of features to be developed over time. The desirable features of a product are prioritised and then divided by Timebox with the most important features developed first. See the section Release Plan for more details. The division by Timebox is a result of the current velocity of the team being mapped against the current story point backlog for the project.

This is a good time to start the Risks and Issues Log.

See Agile Project Planning, Agile Project Estimating, Agile Risk Management

Initial Requirements

The Product Owner is responsible for delivering the initial requirements during Timebox Zero.

There is no need to provide detailed requirements for subsequent Timeboxes at the start of the project. This will allow requirements to develop during the project with minimum overhead.

In terms of requirements that means doing:

• High level requirements for the entire project
• Detailed Requirements for Timebox One

The high level requirements are for the entire project.  Facilitated workshops are an effective mechanism for eliciting the requirements from the stakeholder group fast. The high level requirements drive the the Release Plan.

Agile is about doing the barely sufficient documentation to facilitate the next step in the process.  That means only enough detailed requirements are specified, agreed and understood to keep the team busy for the first one or two Timeboxes. Ideally the detailed requirements include Visual and User Experience Designs.

Silicon Valley Product Group recommend a a High Fidelity Prototype rather than using documents to describe the target system.

See Agile Project Scope and Agile Project Control

Initial Infrastructure

the technical staff set up the infrastructure for the project during Timebox Zero. This includes:

• Environments
  • Developer and tester machines
  • Servers (development, continuous integration, test, UAT) including hardware and operating system, web servers, application servers, databases and permissions
  • Team Wiki
  • Set up and configure a bug tracker, agree bug process
• • Version control and builds
  • Source Code Control repository (e.g. SVN) with access for developers and tester(s)
  • Tools for Continuous Integration (e.g. Cruise Control, Nemesis)
  • Continuous Integration up and running on your project in your source code repository
• • Test Driven Development frameworks
  • Tools for automated testing (e.g. JUnit, JMock, JSUnit, Selenium, FIT, Fitnesse, DBUnit, XMLUnit)
  • Agree method(s) and depth of unit testing
  • Agree methog(s) and depth of acceptance testing
  • Agree the high level scope and approximate timing or frequency of other tests, for example accessibility, performance, security
  • Decide, set up and configure a framework for acceptance test automation
  • Write just enough code to support the automated build, continuous integration system, and automated test framework in use.

The technical staff, led by the Technical Lead, also do the first high level version of system architecture.  The systems architecture document outlines both the hardware and software of the intended solution. It describes the target platform and (if different) the development platform. It also explains the software structure including major components and their interactions. [Some Agile methods are very keen on emergent design, but you have to start somewhere.]

Environments

Not really Agile per se but I thought it worth having a mention of the environments a development team will need. There are quite a few.

Promotion Path to Live

Environment	Purpose	When to use	Release Control	Who Controls
Development	Where the developer does their thing.	Always	Controlled	Developer
Continuous Integration	Where the continuous integration build appears	Always	Uncontrolled
Automatic System Test	Where the automatic tests run if the Continuous Integration box can’t handle the load.	If have to split test because they run too slow	Uncontrolled
Manual System Test	Where the Testers check out stable releases.	Always	Controlled	Tester
Automatic Integration Test	To integrate all of the components when there are multiple development teams working on a shared product.  Kicked off by an automatic process.	Multiple teams integrating	Uncontrolled
Manual Integration Test	Ditto but for the integration testers to use.	Multiple teams integrating	Controlled	Integration Tester
Hot Fix Development	To maintain a live copy of the software using Hot Fixes, whilst developing new functionality in parallel	When system is live	Controlled	Developer
Hot Fix Continuous Integration	Ditto; this is were the continuous integration build goes	When system is live	Uncontrolled
Hot Fix Pre-production	Ditto; this is were the Hot Fixes are tested before going live.	When system is live	Controlled	Product Owner
Pre-production	This is where manual user acceptance testing usually takes place	Always	Controlled	Product Owner
Production	Live.	Always	Controlled	Product Owner or Operations

References

Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.

DSDM Consortium. (2002). Framework for Business Centred Development:Handbook for DSDM Version 4.1.. Author.

Project Management Institute. (2004). A Guide to the Project Management Body of Knowledge (PMBOK Guide) [3rd Edition]. Author.

OGC: Project Initiation Document (PID)

Silicon Valley Product Group

Wikipedia: Conway’s Law