Val IT to define the concept of “value” (the first Lean principle), and how this concept branches out to application development, affecting Agile development. Clearly Val IT is aimed at the executive management level, both in business and IT, so the questions that remain are how this can possibly “flow down” to an application development team, and what the benefits might be. The first thing to point out is that Val IT is undoubtedly much broader than application development.
And knowing this, we certainly don’t want an Agile pod to be distracted with the details of an executive-level governance framework, of which the practices are far from the reach of the development team. But let’s take a closer look at this. According to the ISACA Web
site, Val IT establishes that “IT-enabled investments will include the full scope of activities required to achieve business value.” This means that to realize value from IT-enabled investments, we have to go beyond delivering IT solutions and services (IT projects), and
include things like changes in business processes, skills or even the business itself.
This concept changes the notion of an “IT project,” because it blends IT and business together. Therefore, it changes the notion of a successful project, because the project no longer makes sense when detached from the program into which it was inserted. In fact, Val IT determines that “IT-enabled investments will be managed through their full economic lifecycle.” Roughly speaking, this means that success cannot be measured when the project is delivered – it’s necessary to consider the business goals that were initially established for the whole program and to monitor them over a period of time significantly longer than an application development
lifetime. Does it make sense for the project team to even know about this? I think it does, for a number of reasons.
The first is because the relationship between the organizations (the business and the IT organization, including vendors) and people in these organizations should not be transaction-based, but long-term. Only then lean principles such as “seeking perfection” (continuous improvement) and “flow” be attained.
So, assuming that this is a long-term relationship, it makes sense for the IT organization (down to the app dev team level) to (a) understand the program life-cycle benefits, and to (b) be aware of how this has been monitored and the results have been. For once, it creates a real sense of partnership. People feel fulfillment when they understand their roles in a bigger accomplishment. But there’s more to it than this. It’s a bi-directional system, because when people know the expected end results up front, they can proactively participate and suggest things that will make the task easier, adding more value to the value stream.
People feel that they can make a difference and that their contribution is appreciated, just as workers in a lean manufacturing plant feel more challenged (and more valuable) than mass-production workers. And their contribution is indeed greater. Of course, there also has to be accountability – if things do not go as expected, what could have been done differently so the odds of success would be greater? Can we still do something to fix the route and achieve success? Should we retire the program? In a separate post, I’ll delve further into the principles of Val IT, and examine them in broader context within the discussion of lean IT and agile methodologies