English | EN 
From the start of my career, I have had the privilege of being a solution creator. Someone that leverages IT solutions and software to create new business capabilities and solves real business problems. To create these solutions certainly requires a clear understanding of the functional requirements. That is the set of requirements that define features and capabilities needed by the business stakeholders. For instance, a solution may need the ability to search for customers, update inventory or make a payment for a product or service. Traditionally, these features and functions were documented in functional requirements documents and are now more often recorded as a collection of user stories, that roll up to an Agile Feature.
In addition to functional requirements, however, a project’s success can often be determined by how well it addresses the non-functional requirements. Non-functional requirements may include specifications for security, scalability, performance, availability, and other attributes that may adhere to compliance, IT standards or have a direct or indirect impact on the end-user experience.
It is typical for Agile teams to ensure solutions are created to adhere to both functional and non-functional specifications. They can even employ automated monitoring and testing throughout the iterations, to ensure quality and alignment with specifications (and PI Objectives).
However, the architect and consultant in me, knows this alone will not always guarantee a project’s success. In the end, a solution is only as good as the problem it solves or the business value it creates.
This is where Outcome-Based Requirements come into play. An Agile team can develop the best “widget” in the world, but if it doesn’t create business value history will deem it a failure. That’s right! It’s easy to forget, but even projects that are delivered on time, on budget and to specification can be a colossal failure (and waste of money and resources) if it does not deliver business value. I would go as far to say, it’s a failure if it does not deliver more business value than the investment in time, money, and resources it took to deliver the solution in the first place.
In the article entitled “The Role Of PI Objectives” by Eric Willeke, it mentions that “one of the key risks that have plagued every software development approach is ensuring that the initial intent (scope) was clearly understood and articulated by the stakeholder, transmitted effectively to the development team, and interpreted in the same way.” The article continues to articulate, a second hidden value of PI Objectives which is to help shift focus from the feature language and onto the desired business outcomes. This article even provides the following set of key project team questions, which I believe are essential tools in helping to ensure a project’s success:
“Is our goal to complete the listed features, or is our goal to provide the outcomes desired by those features? In other words, if we could provide the same value with half the amount of work, and without building all of the features, would this be acceptable?”
For me, the most exciting point “The Role Of PI Objectives” highlights is what I call Outcome-Based Requirements (OBR). As I began to really consider OBRs as an architect and as a consultant, I came to consider that most organizations have 6 basic and essential needs as follows:
- Need to increase revenue
- Need to reduce expenses
- Need for continuous innovation
- Need to quickly evolve
- Need to optimize and be more efficient
- Need for brand elevation
These six essential needs have been said many times before and in many different ways; the point is that so often in software and solution development neither the functional requirements or non-functional requirements (for which Agile and development teams commit to delivering), can always be guaranteed to move the needle on these six organizational needs. By focusing first on the outcomes (i.e., the specific combination and sequence of organizational needs), a project has a much higher chance of being a success. In the end, it is about value creation, not widget creation!
