KPIs for Change: Project and Product delivery

Along the maturity journey, organisations learn to integrate best practices to improve the quality of
their project management and change management initiatives. This leads to a set of KPIs that reconcile
general project needs with the reality of the company. Often, this concerns lessons learned and best
practices coming from Waterfall managed projects. With the increase of product delivery focused
projects managed with agile practices, it is worth looking enriching the KPIs.
Waterfall & Agile Project Management
Generally speaking, Waterfall and agile project management are defined as follows:
- Waterfall: Sequential project management methodology, in which project progress is regarded as a
downwards process. Originally described as consisting of phases for Requirement Specifications,
Design, Construction, Integration, Testing, Installation and Maintenance, variations exist on the
naming and number of phases.
- Agile: Project management methodology, in which the development is characterized by the
breakdown of tasks into short periods, with frequent reassessment of work and plans. Used in
software related projects, product delivery, and web related projects.

Whereas the definition of a project is comparable in both approaches, the project management as
such is organized differently. Agile Scrum, for instance, divides responsibility among more than one
person. In essence, there are three roles: product owner, Scrum Master and the team.
The product owner is responsible for the business aspects of the project, including stakeholder
management and ensuring that the appropriate product is built in the right order. He/she works closely
together with the Scrum Master and the project team. The Scrum Master is responsible for the
definition, with the team, of how the project scope is realized. He/she coaches team members to work
together in the most effective way, and removes impediments and performs typical project
management duties such as tracking progress and issues. The team
itself assumes project management roles when deciding who "Any intelligent fool can
should work on what tasks. make things bigger, more
Agile Kanban does not prescribe any roles. Roles and complex, and more violent. It
responsibilities should emerge and evolve based on the takes a touch of genius and a
organizational maturity and the understanding of the development lot of courage to move in the
process. At the same time, Kanban projects still bridges with opposite direction."
organizational stakeholders and ensure that results are delivered A. Einstein
while respecting time or scope constraints, and ensuring quality.
It is worth noting that some organisations start with Scrum and evolve towards Kanban, or the other
way around. Shaping agile projects is thus not about opting for one or the other, but rather about
evaluating what is best from both methodologies to support the project goals, while remaining agile.

Throughput & Velocity

Agile is increasingly used in projects focusing on product delivery, web related projects and the like.
When focusing on the Change Management dimension of projects (and the related KPIs), it could be

JRGEN JANSSENS
argued that there are no notable differences between traditional project management and agile driven
projects, as the stakeholders remain virtually the same.
This is partially true, which explains why many change related project KPIs can be kept. As the agile
process to come to these results differs, however, it is relevant to monitor also the efficiency of the
project teams, even if this is strictly speaking not a Change KPI.
Throughput and velocity are ways of measuring how fast a team can do work. Knowing how fast a team
is going allows the team and their stakeholders to know when something is going to be done, despite
the different degrees of freedom coming with agile Scrum and agile Kanban, compared to Waterfall.
Velocity
o Velocity is the rate at which an agile project completes work. It is not used to measure
progress as such, but to accurately estimate the teams capacity for future iterations
and guide the team and product owner in planning upcoming iterations.
o In the first iteration, a project team has no velocity. But from iteration two onward,
velocity is derived from the amount of work the team completed in the previous
iteration or iterations. It can be expressed in story points or ideal time (time spent
exclusively on the task, with no interruptions and in good working conditions). The team
may determine its velocity by averaging the amount of work completed to date over the
number of iterations completed (work/time), or simply by taking the amount of work
completed in the previous iteration and carrying it forward.
o The major challenge: Velocity is based on an abstract unit Story Points that are not
always easy to explain to stakeholders. To get around this some teams estimate in ideal
hours. Velocity also requires the team to spend time estimating the work. As in every
estimation, the results are only as good as the information at hand or as previous
experience allows.
Throughput
o Throughput is not commonly used in software development, but is becoming more
prevalent with the introduction of lean concepts. Throughput is most common when
using Kanban to help manage the delivery.
o Throughput is the number of things that can be done in a given period of time.
o The major challenge: Throughput requires a project to have relatively similar size work
packages. In contexts with stable teams working on products, the Kanban/throughput
combination tends to offer
greater value. It involves less
planning, while offering the
possibility to tell project
stakeholders how much
work will delivered in the
next period.

In short, as most agile projects are supposed

to work either in fixed time / flexible scope,
or fixed scope / flexible time, anticipating
and channeling possible overflows by knowing the pace of work of the teams is key. Taking this into
account through the management of velocity or throughput (and working to improve it), is a way of

JRGEN JANSSENS
making the output 'controllable', and consequently also the associated Change. Without it, Project
Management and Change Management quickly becomes a last minute job or a firefighter job.

Bidirectional benefits

Including agile aspects at the cross roads of Project and Change Management KPIs is also valid in the
other direction.

For the time being, agile projects tend to dedicate less attention to the Change dimension. Simply
introducing basic Change Management concepts to agile project teams can however contribute to
foster positive Change. For instance, taking into account Change aspects of customer-focused work
packages can tangibly improve the way IT and business sides of an organization work together. The
resulting synergies increase confidence and provide a means to measure and track success of not only
the technical quality of the product, but its acceptance by end-users.

A basic approach to do so is by integrating Change into the agile process by simply having Change
Management requirements progress through the same processes as technical requirements, including
user stories, acceptance tests and the iterative development of deliverables. Similarly, having users and
developers periodically in the same progress meetings and stand-ups can contribute to this dynamic.

By integrating Change aspects into agile projects, teams can escape the project stovepipe and therefore
extend their vision to the organisation at large. Although Change Management does not give the project
team absolute control over its destiny, it can substantively expand the domain of its influence. Taking
into account Change in agile as well as including agile metrics in the project KPIs is therefore of great
value for the Change focused Project follow up.

Information about the Author: https://be.linkedin.com/in/janssensjurgen

Information about QSpin : http://www.qspin.be/index.php/about-qspin/

References & Further Reading:

Bogner, M., Elfanbaum, D., (2011). An Agile Approach to Change Management, Retrieved Feb 20, 2017,
from http://www.cio.com/article/2410953/change-management/an-agile-approach-to-change-
management.html/
Cohn, M., (2012). What is Agile Project Management?, Retrieved Feb 14, 2017 from
https://www.mountaingoatsoftware.com/agile/
Janssens, J., (2017). Digital Transformation journeys in a Digitized Reality, in: Khosrow-Pour, M., (2017).
Encyclopedia of Information Science and Technology, Hershey, PA: IGI Global.
Jongerius, P., (2012). Get Agile, Amsterdam, The Netherlands: BIS, 150-159.

JRGEN JANSSENS
 Kniberg, H., Skarin, M., (2009). Kanban and Scrum Making the Most of Both, Retrieved Feb 10, 2017,
from http://www.infoq.com/minibooks/kanban-scrum-minibook/
Office of Government Commerce, (2010). Managing Successful Projects with PRINCE2, 2009 Edition,
Norwich, UK: TSO.
Project Management Institute, (2013). A guide to the Project Management Body of Knowledge (PMBOK
guide), Newton Square, PA: Project Management Institute.
Steyaert, P., (2016). The Kanban Experience, Humbeek, Belgium: Okaola.
Schwaver, K., (2003). Agile Project Management with Scrum, Redmond, WA: Microsoft Press, 67-82.
http://agiledictionary.com/ | https://www.atlassian.com/agile/metrics

JRGEN JANSSENS