On how technologists either endure the wait or the blame in IT projects and why ITIL v3 could use an extra bit on business requirements.
Here is your PMO’s and technologists’ dream, in short:
A business case has been approved already for an IT initiative. A group of business process owners and subject matter experts walk into a requirements workshop, and as solution designers sharpen their pencils to begin elicitation, the business crowd starts passing around activity diagrams that describe in detail how tasks will be carried out in the context of the new system. Not only that, business folks also have brought these neat “use case bundles”, organized by process, and describing business requirements and business rules for the new system, risks and opportunities the business expects requirements will address, etc. There is even a measure of monetary value anticipated from each requirement.
Some eyes glisten as a business manager sets aside on the table “just in case” a separate list of requirements that will be out-of-scope for IT: The line of business has actually identified many feasible changes to existing processes that could address some requirements without resorting to IT implementations.
That is the “requirements engineering” dreamland assumed by ITIL v3. Take a look at it in detail:
If you have read part 1 of this post you would notice what is different in ITIL v3 compared to my previous “ad-hoc” description of prevalent IT project workflows. In ITIL v3, technologists assume that business stakeholders already know their business requirements when the Service Charter is issued (tollgate 2 in the diagram). IT expects the business to arrive to this "dream" Service Design workshop ready to discuss gaps in current IT services, and to check through tollgate 3.
Unfortunately, instead of the ITIL dream scenario, it is more likely that business stakeholders would arrive to the workshop with a work product that is still somewhere before tollgate 2. Their listing of business requirements would look more like an uneven mix of business needs and envisioned system functionality, brainstormed and gathered in excel, and “validated” in the sense: Yes, I need this, but without a solid business process context to establish priorities, let alone a measure of expected ROI for each requirement.
In all fairness, is there a formal process (with allocated time and resources) telling the line of business that they own the task of delivering quality business requirements, after a business case is approved? It is understandable that business stakeholders would postpone until joint design the “work out” and definition of business requirements, because usually this is the only allocated time with resources they find in the project. With no other options, business stakeholders trust that meeting with IT will help them visualize better the future state of processes. Come the workshop, they are trying to catch up to tollgate 2 while IT wants to run to tollgate 3.
Joint design time is the closest many businesses can get to business process improvement time. Is it surprising that IT projects can become solution-driven in this context?
Back in 2011 when ITIL v3 came out I was disappointed because ITIL is such a complete framework, and yet it does not spell out clearly the governance on business requirements.
ITIL v3 does state that business requirements should be ready at the end of Service Strategy (as input to start Service Design) but it fails to mention any tollgate or accountability to validate these requirements and their quality and form. We are left to think that the ITIL framework expects business requirements to be completed and included in the business case (Tollgate 1!), as part of the sub process “Define and Analyse new Services” during “Service Strategy”.
Now this is really dreamland. How many organizations are this thorough when they prepare a business case? Should they really be?
Don’t get me wrong, this is constructive criticism from an ITIL fan. I think ITIL is part of that “Mountain moving closer to the prophet” metaphor I used in part 1 of this post, because the framework is now centered on an approach to help IT provide business value from the start (partnering with the business earlier during Service Strategy).
Let’s just “tweak it” a little bit, until they come out with v4:
If your organization has implemented ITIL v3, I would suggest you consider requiring the line of business to own and deliver a business requirements baseline, as described in my “dream scenario” at the beginning. This work product should be a mandatory component of your Service Charter.
If the line of business does not have the capabilities to deliver this work product effectively, your PMO could “sponsor” the analysis by assigning a requirements manager who would be capable of facilitating it during service strategy (yes, someone will have to assume the cost of this business analyst in the project budget, even if his work is unrelated to IT delivery)
I leave you with four reasons why I would discourage organizations from moving forward and initiating Service Design without this validated baseline of business requirements:
IT will find itself employing solution design resources to bridge a gap on business analysis work that should have been completed internally by the business.
The team will confuse Service Requirements (which are really gaps in current service) with business requirements. The project becomes “solution driven”
IT solution designers are not expected to have a stake in the business process, but even if they try to backpedal to reconstruct any missing link to expected ROI value, they can be perceived as slowing down delivery. Suddenly, a business issue becomes an IT issue.
You will be missing an opportunity to decrease your IT delivery turnaround times, as definition of business requirements would otherwise be recognized by the organization as a task owned by the business, pre Service Charter, and out of SDLC.
ITIL® is a Registered Trade Mark of the Cabinet Office in the United Kingdom and other countries.
By Larry Velarde, CBAP®
