On how technologists either endure the wait or the blame in IT projects, and what CIOs can do about it.
The burden of proving project ROI is on business sponsors; however, the challenge is on the CIO and on technologists in general to perform a careful balancing act of partnering to deliver solutions that meet the sponsor’s expected ROI, while facing extreme pressure to always implement ASAP.
It is only fair that for IT to share this responsibility on expected value from projects, the business should ensure a clear handover of its expectations (Yes we are talking about monetary return on product delivered) via stating and restating ROI at critical decision forks during the project.
As straightforward as it sounds, I believe that in many organizations there is an accountability gap complicating this handover during one specific phase in the IT project lifecycle.
Let’s have a high level view of an IT project workflow, represented in the diagram below as five consecutive tollgates in which the expected value of a project is stated or restated, and handed over to players in the next stretch. The representation spans from enterprise analysis (pre-project) all the way to final delivery in sprints:
First, let us congratulate us all for what works:
Tollgate 1: Thanks to the CIOs’ championing of strategic portfolio management via PMOs a couple of decades ago, nowadays no one questions calculating the ROI of different business initiatives during enterprise analysis, and stating it for approval via business cases.
Tollgates 3, 4, and 5: Again thanks to progress in IT project management and the adoption by technologists of change-driven approaches during delivery (AGILE, Customer Centered Design, etc.) the product owner becomes a partner who states and restates expected ROI during joint design, statement of work negotiations, backlog grooming, and sprints.
But let us focus on Tollgate 2. What are its “passage rules” in your organization?
No one expects IT solution designers to determine product gaps having only a business case as input. A preceding analysis, produced strictly in the business domain and by business process owners, needs to be constructed into Business Requirements Documentation (BRD) and validated prior to engaging IT.
Unfortunately, the criteria followed to approve this BRD vary widely across organizations. Some have built enough project governance on the business side to demand full business process analysis and reengineering as context to each requirement, while others only ask business stakeholders to write down a list of concerns and signed off requirements.
To ensure a clear handover of expected ROI from a solution, the BRD needs to meet two “passage rules”:
1) Each business requirement should have a measure of expected value, an approximate monetary figure pinned to the stakeholder’s concern generating the requirement. (This is to track the stand-alone value of the requirement)
2) Each business requirement should be traceable to the business need established and validated by the project sponsor in the business case, and to other dependent requirements. (This is to track the aggregated value of the requirement)
If business process owners in your organization are not working out these numbers and dependencies in their requirements baseline, and yet the project advances through Tollgate 2 and initiates joint design, your IT resources are being brought in too early into the picture.
This seemingly low-level business analysis issue impacts the share of responsibility on expected value delivered by IT:
Without an effective tollgate 2, IT will find itself employing solution design resources to bridge a gap on business analysis work that should have been done internally by the business.
IT solution designers are not expected to have a stake in the business process, but even if they try to backpedal to reconstruct the missing link on ROI traceability, they can be perceived as slowing down delivery. Suddenly, a business issue becomes an IT issue.
Unfortunately, the “fix” to this gap in accountability on requirements definition is beyond the tactical reach of the IT project manager: In organizational terms, it is not until business stakeholders partner with IT to initiate joint design, that technologists can discuss ROI, business process analysis, or changes in processes as alternatives to product features; however, as we argue above, at this point IT is already underutilizing resources.
What can technologists do? How can the CIO and the PMO help?
First of all this is “nobody’s fault”: It is possible that within the same organization, different business units might come better prepared to explain expected ROI for product features. What is really lacking is a standard on business analysis work before joint design.
Contrary to the business case, which is a clear tollgate that requires stating ROI on business needs, the criteria to convey ROI through business requirements documentation is not owned by anyone on the business side.
IT has control on tollgate 1 through the PMO and on tollgates 3, 4, and 5, through the PM, but IT cannot afford waiting for the business side to establish appropriate passage rules for tollgate 2.
It has not happened in 20 years. It will not happen. It is not a lack of available tools (Six Sigma and Lean can be used effectively to address this issue) it is an organizational gap: in between the business case and the solution design there is no spotlight!
The prophet will have to move closer to the mountain instead. IT will have to “sponsor” the business analysis work done as a preparation to joint design, even if this work means facilitating analysis beyond IT, strictly in the business domain.
In this scenario the Business Analyst plays the role of a scout sent by the Project Manager, advocating project governance, as set by the PMO (developing to-be business process contexts as mandatory for all requirements, exploring process change alternatives, pegging expected ROI on all requirements, etc.)
For this to happen we need the strategic drive of the CIO.
2013 By Larry Velarde, CBAP®
