Agile PDF - Initiation Workshop

Once the customer project has been qualified, it’s

recommended to have an Initiation phase workshop on
the customer’s premises to discuss and explore the
why/what/how/when/cost/risks of the project, with
particular focus on the initial high-level functional and
non-functional requirements that will be used for a
high-level estimate and an understanding of the project
scope.

Ideally, it’s best to discuss and explore the why/what/how/when/cost/risks of the project face-to-face with the customer
on their premises. This allows:

Clear communication, minimizing misunderstandings

All parties to get to know each other personally, greatly helping the working relationship
Project team to see how the customer works at their office in their environment
Dedicated time to focus on the topics instead of using emails, conference calls, etc.

Typically this workshop will be around 1-2 days, however, it can be slightly longer/shorter depending on project
size/complexity and the number of people involved. The key is that the project team receives enough information to
estimate high-level effort and create a high-level project and cost plan.

Prepare Workshop

Preparation is key for the workshop. With only 1-2 days of workshop discussions, it's important to have an agenda (a list
of topics/features to be discussed) and to time-box the agenda to ensure all topics are covered at an appropriate depth.
From a functional perspective, the objective is not to get detailed requirements, but a high-level understanding of
complexity and prioritization for each feature to enable high-level estimation.

Project, functional, and technical expertise is needed from the project team representatives for the workshop, so
attendees need to be planned appropriately. Appropriately expert and responsible people from the customer are also
required. Also, any important dependent third parties should also be represented.

If a pre-sales team has previously been involved with the customer, it is helpful to see the same demos that they gave
to the customer beforehand, to understand the customer’s expectations going into the workshop. Depending on the
situation it might also be useful to have the pre-sales person attend the workshop.

The workshop agenda should be agreed and finalized with the customer beforehand. Topics should be time-boxed into
1-2 hour slots so that all the material can be covered.

For the functional topics, typically the customer provides a spreadsheet or other document with their requirements wish
list. This can be categorized and used as the functional agenda structure. If not then a standard list of functional topics
can be used.

Typical topics to consider for the workshop agenda are:

Customer’s vision, goals, and objectives of the project, as well as challenges they see today and potentially in
the future
Present the Agile Project Delivery Framework & ways of working
High-level functional requirements & prioritization
Non-functional requirements, e.g. performance, scalability, security
High-level system landscape and integration points
Key milestones, e.g. project start, release roadmap and go-live dates
Third-party dependencies
Data requirements and dependencies, e.g. source/test data and data migration
Project and technical risks
Tooling and ownership
Hosting, infrastructure & environments
Organizational/team structure
Project governance
Testing responsibilities
Stakeholder analysis and identification of all involved parties and their responsibilities
Long-term ownership of solution, e.g. development, maintenance, and support
Responsibility for user experience and creative designs

Additionally, the agenda should include any open qualification topics.

Run Workshop

Here are some points to consider when running the workshop:

Tightly moderate time to ensure all topics are clarified only to a level that enables high-level understanding and
estimating. Sometimes customers focus on certain topics, especially where there has been a lot of internal
debate. It’s recommended the customer continues these discussions internally after the workshop in preparation
for the subsequent Foundation phase.
Discuss customer expectations on timelines, go-live dates, and scope while avoiding setting expectations on
being able to meet those before proper analysis and planning.
Once timelines and go-lives are known, discuss splitting the overall project into a series of releases (e.g. 4-6
months in duration). This is to introduce the customer to more frequent releases rather than a single big bang
deployment. When discussing functional requirements (features), these should be prioritized with the customer
into these different releases.
If discussion of a feature starts getting into lengthy discussions and too detailed, it is sufficient to note it as an
area that needs further elaboration which will result in an increased Story Point size to account for the
uncertainty. Plus this also helps identify topics that might need more time when planning subsequent Foundation
phase workshops.
Demos are only needed where they add value and facilitate the objectives of the workshop, so don’t spend lots of
time educating the customer on out-of-the-box functionality as this isn’t the objective, and time will be taken from
more important topics.
Document as much information as possible, this will be needed for later estimations. Most important are the
features to put in the Agile PDF - Initiation Estimation Sheet, but information related to technical, quality and
project considerations should also be captured.
It is helpful to understand budget expectations but be aware that the customer may not want to provide it and
would prefer to receive a cost estimate based on their requested scope not for the perceived budget.
Finish the workshops with agreeing on next steps:

Dates for customer to provide further input (e.g. diagrams, layouts, click dummies etc.)
Dateforprojectteam to provide estimates and high-level project plans. Set expectations that these will be
high-level estimates subject to further exploration during Foundation phase workshops.
Agree on potential start dates for the Foundation phase. This is required for high-level project planning.