What is a project if not an epic journey

One thing we've learned from the first phase of the iHRM program is that a complete waterfall approach with one delivery moment, followed by an extended user acceptance period is not the silver bullet. For the second phase of the program, the scope is wider and the number of project teams is higher. In this blog post, I'll share some insights on how to effectively manage scope while going for an iterative and incremental development plan.

One lesson we’ve learned from our approach of the first program phase was that going live with a bang is a bit (too) challenging. As the project timing was ambitious with no room for delay (the go live date of a payroll system was fixed to January 1st due to several constraints), the foreseen time for user acceptance testing was already partially consumed by unforeseen development time. Several defects detected in this UAT period had underlying root causes that we would have liked to have solved quite a bit earlier.

A different approach

So for the second phase of the program, we've chosen to do things a little bit differently. Our program management has opted to go for an iterative / incremental delivery approach which allows us to deliver the full scope over a number of iterations. Each iteration takes 4 weeks and adds part of the scope. It was foreseen that the last week of the iteration would go to extensive user acceptance testing and (if necessary) defect fixing.

In practice, each project had it's own requirements project plan that assured alignment with the iteration milestones of the program plan. So far so good.

After the second iteration it became clear that the great benefit we were expecting from the iterative approach; accelerate user testing and detect complex issues as soon as possible, could not be realized. The reason? Although each individual project scope was aligned on the milestones, there was a lack of scope alignment amongst projects. If we didn’t change our approach, the end to end testing would only be possible near the end of the delivery phase of the full project. That is; when the last piece of the puzzle for an end to end integration would have been implemented.

The Epic

In order to optimize our way of working, my colleague Philippe Bracke (project manager) and I introduced a new way of taking on the existing scope. Instead of letting each project team decide on its most optimal planning, a business focus was introduced in the form of 'epics'. An epic should be seen as a coherent set of functionality that delivers a certain business value end to end. Each epic is formulated as a statement that expresses the value and is accompanied by a set of acceptance criteria that express which value has been realized in a very tangible way.

A real life example of an epic: 'an employee can be planned based on his HR master data and the defined work packages' has the following acceptance criteria:

• The employee's contractual work schedule is known by the integrated resource allocation tool.
• Employees can be planned in a flexible way in line with their contractual agreements.
• HR's operational activity types can be used to define operational work.
• Operational work can be assigned to employees (planning).
• The operational planning can be published and the planned work time is known by HR&O.

This epic implies for the various project teams that:

• All required functionality to manage the employee's master data (contract, function, work time,...) is in place.
• Interfaces are in place to sync this master data with resource allocation tools.
• Resource allocation tools can manage their own master data (the work to be planned).
• Resource allocation tools provide the planning functionality.

How does this work?

By dividing the complete (and quite large) scope of the program in a limited set of epics, we are now able to have a shared focus across project teams. We work on the same things at the same time and can deliver something that works for our testing teams, each and every iteration. We are now also able to gradually increase complexity of our deliverables and get more grip on the actual progress in terms of business value.

Does this mean that it suddenly has become a walk in the park? Not at all, the work that each team needs to perform to deliver an epic is very relative to its scope. We consider the epic as a must for the teams and we ask commitment on the epic's delivery. If a team has time left, they can already put work on the next epic. It is again quite simple once you get the hang of it. It's a bit like my five year old son's kindergarten class: there are things the kids must do and as soon as those are done there's other stuff they can choose to do.

Needless to say that a good and easy to understand (simple!) overall architecture is a key enabler to put this way of working into place. The architecture is the final destination, the epics are the most logical journeys you need to travel.

For those of you that are into tooling: we use Jira agile to manage the full scope of the program and measure its progress.

Thanks for reading this post. Next time I'll bring the business change to the table. A project is a lot more than just implementing software and requires a good deal of business architecture as well to effectively realize the change in your organization.