Outcome Oriented

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 BusinessCapabilityCentric organization.