Project Inception workshop: How to get started-EN

Many times, teams are handed a project and don’t know where to start. Another scenario is that a team was involved in the decision-making process but has to re-position in order to execute their vision. 

A while back I facilitated an inception workshop for what will be our client’s first agile project… I want to share my experience. 

The project objective was to develop a custom back-office tool using Microsoft Dynamics CRM and SharePoint. (They had been using a version of Microsoft Access.) Their intent was to create a new web-based version that integrated with their information systems.

The project had already been authorized using a more traditional approach (pre-analysis, offer, detailed analysis, design, development, etc.), so they already had a fairly advanced requirements document. Also, of note, a contract had been signed with a vendor.

We decided to apply an agile approach to the project from this point on. The first step was to conduct an efficient workshop to agree in more detail on how the team would collaborate (sprints, roles, etc.) and create an initial version of the backlog by transforming the existing requirements document into user stories.

For this session, I planned activities to create a vision, identify roles, define needs, determine benefits, define the product, and create the initial product backlog.

I started the session by asking, “What are we going to do today?” and the unanimous response was “Define user stories.” Mmmm… they went directly to the product backlog. I thought at that time that my initial plan for the session was going to be seen as a waste of time, since there was a requirements document that sat for quite a long time until sufficient resources were available to start. The scope was clear and narrow. So, with some doubts, I continued with the session plan.

Inception Workshop Part 1: Vision and Roles

We defined the vision with the classic Geoffrey Moore model in Crossing the Chasm, and which SAFe also uses in their definition of an Epic:

• For (target customer)
• Who (statement of the need or opportunity)
• The (product name) is a (product category)
• That (key benefit, compelling reason to buy)
• Unlike (primary competitive alternative)
• Our product (statement of primary differentiation)

By the way, whenever I use this technique, I always find it a bit difficult to differentiate between the need and the benefit without having a feeling of repetition.

While working through the Vision, we realized the participants had different expectations. We talked through these and reached an agreement. We concluded that the new back-office tool was as important as the management processes associated with its use. Important point.

Next, we defined the roles with a collaborative model. We got 19 (!!!) different roles. Although we understood that initially there would be fewer roles, and that later some would be merged, at this point we began to see that the project could become more than we anticipated. We debated, time went by, and we got to the heart of the matter: the product backlog.

Inception Workshop Part 2: Product Backlog

I explained Jeff Patton’s model on how to make a User Story Map, and we started modeling the skeleton with the primary workflow. At this point we tried to create an MVP, since the workflow was complex, with different statuses, business rules, and triggers.

The key point learned here was that when we went into detail on the skeleton, we saw that “everything is a must,” and that it was going to be difficult to reduce. “We have to have the same functionality that is now in Access. We cannot start with less; it would be going backwards.”

At this point, the most revealing dialogue of the entire session appeared:

• If everything can now be done with Access, why even make a new version?
  • To integrate with our systems, have web access, and some added improvements.
• Is that worth all the effort?
  • Well, now Access is not used at all, information is missing.
• Not used at all?
  • There is not 100% reliable information. Users do not report all the necessary fields, so we do not know if the content is current.
• And why don’t users report it?
  • Well, day-to-day… you know… it is just one more step, and if you can save yourself from having to do extra things, then that’s better.
• But the information is relevant. If it were centralized, we would save a lot of time managing it.
  • Yes, that’s correct. But it is not used.

From that point on, the focus changed. It was not about breaking functionality into user stories. It was about seeing what was wrong with the current version, finding the reasons, looking for an alternative, and focusing on not making the same mistakes. Something that could already be deduced in the “Unlike” of the vision, but that was overlooked.

We removed all business rules (being able to make any change without following a workflow, not typifying entities – all of them). We focused on defining the benefits and making a new version centered around:

• user collaboration during workflow
• ensuring updated information
• centralization and versioning of documents
• centralizing associated conversations

Results

The objective was to prevent the tool from becoming just another bureaucracy that held no reliable information, that was useless because the content was incomplete, that forced the “I better look at the last email they sent about this…” – in short, to avoid the reasons that made the current version useless.

We wanted users to love the tool. We wanted it to be the first thing they went to in the morning to see the status of their work and to determine their next steps.

The scope at the end of the session was nothing like the one in the requirements document at the beginning. No one had thought to focus on the collaborative aspect and how to ensure that it would be used. The supplier contract was little more than wet paper, but we all realized that building what was written would have been making a product useless. An “Access 2.0”.

As of today, I don’t know how this project will end. However, I bet I can guess where it would have ended if we hadn’t conducted this critical initial session: in a drawer, along with the current version.

Let me know we can help you kick off your project (or help discover why not to move forward)!

— Miquel

Schedule a Project Inception Workshop for your team or see our Agile Project Inception course outline for comprehensive training.