Author: Terry Longo

Managing Requirements: Can ITIL help?

Written by Terry Longo on April 14, 2008. Posted in Articles.

Over the last six months I have presented to numerous audiences on the topic of how Business Analysis and IT Service Management (based on ITIL) can work together, indeed must work together, to drive the level of quality and cost-effectiveness we are all seeking within the IT solutions space.

Interestingly, there has been a notable difference in the nature of the feedback

PM/BA audiences (such as those at the Project Summit / BA World events) have provided fairly positive feedback (and in fact the trend is upward over time)
ITIL knowledgeable/experienced audience feedback has been overwhelmingly positive, to the point where they are asking to have the presentation brought to their own organizations!

I am predicting that over time, as BAs look for additional ways to strengthen the rigor of their business cases, they will increasingly rely on the IT organization’s use of ITIL as a basis for defining and driving fundamental BA/IT interactions, including change management and financial characterization of solution development, deployment, and operation.

If you are a BA, do you work within or with an ITIL-based IT organization? If so, can you identify specific benefits that have emerged from the IT organization taking the ITIL path?

Terry Longo has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through http://www.hp.com/education/sections/pm_bus_analy.html or at [email protected]

Enterprise Requirements Alignment: The Top Three Challenges

Written by Terry Longo on March 31, 2008. Posted in Articles.

1. Change Management as an enterprise core competency. Consider any particular requirement. At any point in time, one of the following is true:

The requirement is valid but not being met – in which case some aspect of the solution must be changed.
The requirement is not valid (even if it used to be) – subjecting it to further iterations of the requirements life cycle and corresponding changes to the underlying solution
The requirement is being met and will remain valid for the foreseeable future – in which case attention will turn to changes to the solution for increased efficiencies. (This means, by the way, that even the “as is” operational elements of an enterprise are as subject to change as the transformational elements.
In other words, if the requirement is not being met, change is necessary. And if the requirement is being met, change is necessary. Earlier posts to this blog have said plenty about the position that everyone in an enterprise is carrying out requirements management within their respective domains. But what is requirements management but a specific form of change management?

2. Financial Fluency as an enterprise core competency. It is easy to construe scenarios in which the failure of even a single small-scope technical component of an IT based business solution can totally eliminate the solution’s business case. That means that senior management’s view of the solution’s status throughout the life cycle would ideally assimilate the status of that component, requiring the component’s owner to be able to express status in senior management terms of cost, risks, and trend. In other words, each contributor to a solution needs to be financially fluent within his or her domain. And, every time a change must be accommodated, contributors to the solution must reflect how that change impacts the financial picture for their own contributions.

3. The Business Analysis Center of Excellence (BACOE). Enterprise-wide consistency in managing changes to requirements and solutions, along with consistency in measuring, monitoring, and status reporting across, up and down the enterprise requirements hierarchy, demands an enterprise-level entity. This would serve to define and drive the implementation and continuous improvement of best practices in change management and financial management.

You might notice that I have not included in the top three the selection of a tool to underpin enterprise-wide change, requirements, and financial management. Tools are easy. The real challenge is driving the enterprise culture to the point where an understanding of one’s job in terms of requirements management, change management, and financial management is second nature.

The Language of Alignment

Written by Terry Longo on March 14, 2008. Posted in Articles.

Business benefit, growth, and profitability. Cost and risk. Value add. Forecast confidence. Customer satisfaction and loyalty. These are the measures of senior management. And if the goal of a commercial enterprise is to make money now and in the future, everyone in the enterprise needs to be behind that goal.

You manage a business unit and are looking at a red/amber/green dashboard report of your current programs, and you see that one is red. With your browser, you drill down the trail of red, each click bringing you to a lower level dashboard with more detail about a specific aspect of the at-risk program. Here is what you find:

The business’s success with a new product line is at risk because
The sales teams might not be prepared to sell the new product line because
Sales training for the new product line may be delayed because
Implementation of the Learning Management System (LMS) may be delayed because
The LMS module used for the management of training records may be delayed because
Development of the core code library for that module may be delayed because
The lead developer may need to leave the project due to an important and urgent personal matter

While the above may seem dreamy, it’s where we’re headed. Everybody in a value supply chain, from the lead developer to the LMS implementation project lead, to the sales team manager, to the business unit manager should, at any point in time, be able to express the status of his or her responsibilities in terms of Cost, Risk and Business Benefit.

The costs, risks, and benefits of what, you may ask? Simply put, for each person or team in the value supply chain, the costs, risks, and benefits of meeting their requirements.

Previously I have argued that the requirements management activities of planning, eliciting, etc. are necessary regardless of the domain in which one is working (instructional design, business strategy, database design, etc.). It is not only possible, but necessary, that requirements managers in those domains be able to express their status in terms of cost, risk, and business benefit. Rolling up requirements status to a senior level necessitates a common language, and that language is defined by the top-level requirement(s) of the enterprise.

We have much to do. In my next post, we will elaborate on the above and identify the top three challenges in achieving the dream.

Do you have any thoughts or questions about this post and earlier posts? Please don’t be shy! Let us know what you’re thinking by adding a comment below.

or at [email protected]

Fill-in-the-blanks: A Process / Content Framework

Written by Terry Longo on February 15, 2008. Posted in Articles. 1 Comment on Fill-in-the-blanks: A Process / Content Framework

If you’ve read the previous entries in this blog, you have seen that we’ve been building up to something, and this new entry will hopefully bring us to our first conceptual plateau, upon which there is much more to build.

What we’ve done so far is to reorient our view of requirements and the BABOK, by going from this (based on BABOK 1.6):

to this (based on IIBA guidance on BABOK 2.0 direction and the concepts from the three previous blog entries):

Following the previous blog entry about content vs. process, we are naturally led to the above structure which manifests that distinction and also provides a framework within which we can indicate the appropriate methods, tools, techniques, and standards for the corresponding process phase, within the corresponding language domain.

For example, in the Software Development x Elicitation cell, we would typically find UML, prototyping, consideration of legacy systems, etc.; while in the Enterprise e-Learning Infrastructure x Elicitation cell, we might find multimedia complexity requirements analysis, consideration of training data privacy laws, task analysis, etc.

This view brings up some interesting questions about

Ownership of the process itself (process design, continual improvement, and governance)
Whether this view contributes to or hinders senior management’s ability to obtain a dashboard view of the benefits, costs, and risks related to current requirements management efforts
The potential benefit to the enterprise as a whole should this view be adopted by managers and individual contributors involved in managing or meeting requirements

We’ll tackle one of those in the next entry. Meanwhile, I, and I am certain your colleagues, would love to hear your comments.

Enterprise Analysis: Process or Content?

Written by Terry Longo on January 31, 2008. Posted in Articles.

In earlier posts, I have been reasoning that the IIBA and BABOK are on their way to defining a generally applicable framework for requirements management best practices, and that the BABOK 2.0 will be the first significant manifestation of the distinction between process (the requirements life cycle) and content (the nature, or domain, of the requirements being managed).

Viewing the requirements management life cycle in that way, however, requires us to scrutinize the way in which Enterprise Analysis (EA), as currently defined in the BABOK, fits in:

EA is content because it is carried out specifically in the domain of business planning and business strategy.
EA is process as well, because it is a crucial first step in the requirements life cycle.

The question becomes: is there an EA-like step in the requirements life cycle within other domains? Let’s explore this question by considering another domain, that of enterprise e-learning infrastructure and delivery (there are many other domains we could choose as well). From the business strategy point of view, this is a tactical and operational aspect of the enterprise. But from the e-learning director’s point of view, there is, of course, strategy involved, addressing questions about workforce trends, globalization of the enterprise, the presence of electronic performance support practices, learning-related data privacy, and many others.

So the e-learning director must:

Create and maintain the e-learning architecture
Conduct feasibility studies of e-learning infrastructure and delivery solutions
Determine the scope of e-learning infrastructure and delivery projects
Authorize the initiation of those projects
Interface with the project team to manage the projects’ value, track benefits, manage change and risk, etc.

Hmmmm. Looks a lot like BABOK’s Chapter 2: Enterprise Analysis. Which is the point being made. “Enterprise” is the content. “Analysis” is the process. An e-learning director reading BABOK Chapter 2, while pretending the title was “E-Learning Infrastructure and Delivery Analysis” would get some great guidance.