Bliki: OutcomeOriented

People who sponsor development of software usually aren’t very interested in
development metrics such as velocity or frequency of deployment to production. They care
more about business benefits that the software will deliver such as lower manual effort,
better sales conversion, greater customer satisfaction, i.e business outcomes.
Outcome-oriented teams are those that are mandated and equipped to deliver business
outcomes, such teams have people with the capability to carry out all necessary
activities to realize the outcome.. By contrast, ActivityOriented teams are neither
equipped nor mandated to do so. They can only perform one of several activities required
to realize an outcome.

A mandate to deliver a business outcome is very different from a mandate to deliver a
certain amount of scope. Scope delivery is easy, relatively speaking. Outcome
realization requires real collaboration between those who understand the problem and
those who can fashion various levels of solution for it. Initial attempts at solution
lead to a better understanding of the problem which leads to further attempts at better
solutions. This doesn’t work where the product management organization is separate from
the development (scope-delivery) organization.

Outcome-oriented teams are necessarily cross-functional (multidisciplinary) whereas
ActivityOriented teams are typically mono-functional (single specialty). In the most
traditional scenario, an outcome might simply be defined in terms of a project. The
project is funded on the basis of a business case and therefore the desired outcome is
to realize what is promised in the business case. However, depending on the size of the
project it may be organized as one or more teams. When these teams are set up along
activity boundaries it becomes an activity-oriented project (or program) organization.
On the other hand, we achieve an outcome-oriented organization by dividing the overall
outcome into sub-outcomes and assigning sub-outcomes to cross-functional teams that are
self-sufficient in terms of people required to deliver the sub-outcome.

Sriram's book goes into more detail on how to build an effective IT organization
using outcome-oriented structures.

A potential problem of outcome-orientation is that people working in the same
activity don’t get to mentor and learn from each other. To mitigate this, set up
communities of practice along with expert community leads who have the ability to mentor
and the budget to organize community events, buy books and arrange for training.

Executing big projects with an outcome-oriented setup is definitely better than doing
so with an activity-oriented setup. That said, an outcome-oriented approach really
shines when we move away from a project-centric funding model. In projects executed with
outcome-oriented teams, the teams don’t live as long as the outcome is relevant to the
business. They are disbanded at the end of the project which means we lose sight of the
outcome until another release in the same area is funded with another team. This also
leads to a problem of instability of management and reporting structure. These are
limitations of the project-centric mode of IT execution, which can be overcome with a
Business Capability Centric organization (post coming soon).

Acknowledgements

Special thanks to Martin Fowler for his guidance with the content, help with publishing and for the nice illustrations.



Share:

if you found this article useful, please share it. I appreciate the feedback and encouragement