Tag: requirements

The Right Question to Ask

Back in the simpler days of IT, there were not that many frameworks or methodologies for business or IT to worry about.

When the business needs something from IT, they talked about what they are trying to accomplish or how things need to work differently.

These days, we in IT asks our business clients to give us the “requirements.”

By following the industry frameworks and methodologies, we look for a detailed write-up on how things ought to look, which systems need to interface with which, data processed in what formats, what are the networking connectivity, and so on.

I have seen many of such interactions between IT analysts and business users. Usually, one or both sides sound unsure or confused. Both sides work hard and try not to offend the others. The conversations feel unproductive because we are not asking the right question.

The right question ought to be… “What are we trying to accomplish and how things need to work differently this time?”

Or just as well… “How do you want your stuff/operation to run differently or better?”

By sticking with the business terms for discussions, everyone can walk away knowing confidently both sides have a common understanding.

Book Review: An Integrated Requirements Process by Peter Brooks

Summary: Compelling recommendations for instituting an integrated requirement management process in any enterprise

After managing IT projects and practicing IT service management for a number of years, the idea of having an integrated requirement process (IRP) for an enterprise intrigues me. I am certified in ITIL and have studied IIBA’s BABOK and ISACA’ COBIT frameworks. I was particularly interested in reading Peter’s recommendations for managing enterprise requirements.

The author proposed IRP based on the premises that:

Requirements are corporate assets and should be methodically captured, tracked, managed, and re-used for the benefit of the enterprise.
Many frameworks describe the needs of capturing and managing requirements but do not go into more details on how requirements should be properly captured and managed
An unified view of the requirement is necessary and can be leveraged by other IT frameworks and activities

Why would you want to read this book and examine the proposed process? I think the book is relevant if you are looking for:

A starting point into a more organized and formalized requirement management process for your organization
Ways to capture requirements from discrete projects into a centralized enterprise repository and to leverage their re-use
Recommendations for integrating requirement management more seamlessly with other IT activities/lifecycles such as application development, business analysis (BABOK), ITSM (ITIL), and IT governance/audit (COBIT).

How would this book help you? After reading the book, I think you will be able to:

Define or design a requirement management process for your organization. For example process flow, roles and responsibilities, recommended CSFs and KPIs
Define or design categories and statuses to enable a requirement managing workflow for logging, tracking, and re-use of the requirements
Define or design the necessary measurements for evaluating the IRP’s effectiveness
Understand or identify the necessary controls for governing and sustaining IRP
Understand or identify the integration points between IRP, BABOK, ITIL, and COBIT
Understand or identify supporting tool requirements

In summary, Peter has provided some compelling reasons and recommendations for instituting an integrated requirement management process in any enterprise. The book has defined all the necessary elements for designing, implementing, and governing the IRP. Peter also has taken a great deal of care by adding plenty of worked examples to help explain the process. I believe his recommendations provide an excellent starting point for those who are ready to manage requirements as corporate assets, rather than just one-time project occurrences.

Problem Management Process Design – Part 2

This post is part two of a series where we discuss the Problem Management process and how to put one together. In the previous post, I presented some design elements for consideration. In this follow-up post, I will illustrate the design activities further with the following, additional elements.

Problem Management Process Requirements

Problem Management Process Flow

Problem Management RCA Form

The first document contains a list of sample process requirements. The purpose of the requirement document is to capture all considerations that need to be factored into the process design. You will need to decide what activities or requirements will be considered a critical part of the Problem Management process. For example, if row #12 “Categorize the root causes to facilitate further analysis” is important to your organization, make sure that particular requirement is documented, so your process design will incorporate a method of categorizing the root causes.

What can you do if you need some extra help on knowing what to look for in designing your Problem Management process? I would suggest using the following documents as your starting point:

ITIL: Problem Management in the Service Operation manual, section 4.4.
COBIT 5: Enabling process DSS03 – Manage Problems
ISO/IEC 20000: Problem Management in Section 8.2

By using ISO/IEC 20000 as the base, I have derived some sample requirements for your reference. As you can see from the document, the sample requirements outlined in the document are pretty rudimentary and generic. You need to tailor your version of the document with the actual requirements from your organization. Do not select a particular requirement just because it looks good on paper or in theory. Craft or select the requirements to include in your process design only when they make sense for your organization. Also, if you plan to implement a tool or have an existing tool that will be used to support the Problem Management process, the tool-specific considerations should be captured in the requirement document as well.

The second document contains a sample process flow. The process flow shows who is doing what and during what stage of the Problem Management process. Once you have determined what your requirements are for the process, the process flow attempts to match and support the process requirements.

The third document is a sample data entry form for the root cause analysis exercise. The form illustrates what data you may want to captured with the process, and they should be consistent with the requirements you have captured from working with your organization. The data you want to capture from the process should also be consistent with the support from the tools you plan to use with the process. Normally, we don’t want to have the tool’s capability drive the process design decisions. If you have an existing ITSM tool that you would like to use for the Problem Management process, now it is the time to factor the tools into the design and make sure the design can be supported by the tools.

In part three of the post, we will combine everything we have done and produce one final process design document. The process design document will include not only the requirements, the flow, and the roles, but also other information pertinent to the process such as the policy statement, a RACI chart, and the process metrics. The final process design document can then be used as the foundation to implement the actual Problem Management process within your organization.