ITIL V3, Enterprise Architecture and Project Portfolio Management, where do I start?

Recently I have attended the ITIL V2 to V3 bridge course and took the examination. It is clear that one day is not enough and a day and a half would have been convenient. IIL V3 is supposed to be an evolution and not a revolution… Pretty sure that a day and a half would have frightened some IT decision makers… and the decision was from trainers to only offer that single day.

As I was prepared for the course (I did some reading before), this was not a real issue...

This being said, after a few days I was wondering how companies would present ITIL V3 to the IT Management team, to a CIO, and obviously the business! The introduction of the Service life cycle is a new concept which requires the buy-in and the sponsorship maybe beyond the IT department! Service Strategy has to be sold, and demonstrates a real value, but this not the point.

Let’s imagine you are in a mature IT department where IT Governance is your daily culture. You may have different IT Governance pillars and among them:

• IT Service Management


• Project Portfolio Management


• Enterprise Architecture

Usually, different teams take care of these initiatives and unfortunately they do not always work together.

The Project Portfolio Management team (PPM) collect business demands and requirements, classify, categorize them, and on an annual basis, do some sort of planning after a budgetary exercise with the business. The PPM team may collaborate with the Enterprise Architecture team to better understand the impact of new demands on the company’s architectures. They may also interact with the IT Service Management for Capacity Management and Service Level Management to better assess these demands.

The Enterprise Architecture (EA) team who already has documented a baseline architecture, define a target architecture (or transition architecture) based on the business drivers, business strategy and with a gap analysis, identify new opportunities, new projects. These new initiatives may afterwards be included in the list of projects and be processed by the PPM team.

With V3, the situation becomes more complex as we have a new way of starting projects! The view is based on the creation of new services which are then included in the Service pipeline and Service Portfolio. In the past, with V2, operational people only had a reactive position. With V3, Service Strategy considers the business view and proposes ITSM as a way to launch new projects!

Isn’t this confusing? Do you think that companies which already have implemented PPM and eventually EA would change the way they classify and launch new projects? Would you go to your CIO and tell him….”...now with V3… we should start with a Service Strategy and consider PPM and EA, either in parallel or afterwards”?. No way! Would you go to your business partners and claim that V3 is a new way of creating new projects and services? Maybe not…

Below I have tried in a diagram to describe various scenarios related to how companies may approach the three domains:

• The PPM view considers new projects with PPM has the core methodology to address business needs. It refers first to Enterprise Architecture and then IT Service Management.
  


• The EA view consider PPM first and finally ITSM.
  
  
• The ITSM view (in fact V3) consider first PPM (Service Strategy) and then EA (Service Design)

It is clear that none of these approaches can be considered as better than the other one. All frameworks include bits and pieces of the others. I may imagine that V3 will make the choice event more difficult and mature IT department will have to evaluate where Service Strategy and Design fits in their IT Governance framework…or consider V3 has being the more innovative and change the company’s culture.

Requirements Management and Enterprise Architecture

I was describing a while ago the relations between Requirements Management and other types of user’s demands.

Let me restate my definition of what that is. Requirements Management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project. The project could be for a new consumer product, a web site, a system or a software application. In all these cases, the five classes of requirements should be represented.

The objective of the Requirements Management activity is to define a process whereby requirements for Enterprise Architecture are identified, stored, and fed into and out of the relevant Enterprise Architecture development phases. As such it forms part of the activities and steps carried out in each of these phases though it is not referred to implicitly in any projects I have managed.

(Requirements Management is also a discipline for both Quality Management (ISO 90001:2000) and Project Management (PMI)).

Target architecture must be based on credible assumptions about future business requirements. Getting these future requirements is not a simple matter of asking business management for them, and analyzing them is not the linear technique used to develop the design for a project. Instead, we have to use a combination of requirements aggregation and scenarios to gather and analyze long-term requirements. This will lead to more credible architectures with appropriate flexibility and evident business value.
For ease of use, it is convenient to think of requirements as belonging to a type.

• Business and Functional requirements

They are the fundamental or essential subject matter of the service or product. They describe what the service or product has to do or what processing actions it is to take.

Business Cases or Scenarios should be used as a useful technique to discover and document these requirements.

Project and Portfolio Management (PPM) addresses the decisions regarding what projects to undertake, with what priority, and in what sequence. Before a project has gone through the necessary requirements definition activities, its scope is based on high-level requirements derived from business drivers, plans, and needs. If these requirements are viewed in isolation, then solutions will be defined in isolation, and they will ignore synergies or dependencies between projects and undervalue foundational projects that provide capabilities that can be leveraged across future projects. Business Requirements also have to be a source for Project Management methodologies.

• Non-functional requirements

They are the properties that the functions must have, such as performance and usability. These requirements are as important as the functional requirements for the product/service’s success.

• Project constraints

These are restrictions on projects due to the budget or the time available to build a product or service.

• Design and architecture requirements

They impose restrictions on how the product/service must be designed. For example, it might have to be implemented in the hand-held device being given to major customers, or it might have to use the existing servers and desktop computers, or any other hardware, software, or business practice.

• Project drivers

These are the business-related forces. For example, the purpose of the project is a project driver, as are all of the stakeholders-each for different reasons.

• Project issues

They define the conditions under which the project will be done. The reason for including them as part of the requirements is to present a coherent picture of all factors that contribute to the success or failure of the project and to illustrate how managers can use requirements as input when managing a project.

• Testing requirements

It is recommended to start testing requirements as soon as we start writing them.
We make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement. If a fit criterion cannot be found for a requirement, then the requirement is either ambiguous or poorly understood. All requirements can be measured, and all should carry a fit criterion.


Requirements Management and Enterprise Architecture cannot be dissociated.

Some vendors have perfectly understood the need of integrating this, such as Telelogic and the need to share a common metadata repository.

With that solution, there are possibilities to go from requirements, to enterprise architecture, to systems implementation and design, with tightly-coupled, bi-directional integration between DOORS (their requirements management tool), and Systems Architect.

IBM has it’s own requirements management solution but has (not yet) an enterprise architecture solution. This may change with the on-going acquisition of Telelogic, but I haven’t been really able to understand IBM’s strategy yet. Is this only a question of absorbing another market or a willingness to offer a full Enterprise Architecture suite in the Rational catalogue? (Requisitepro being obviously an issue….).

The HP approach seems to be the how to integrate the different application coming from the former Mercury and Peregrine world. HP PPM (and HP Quality Center for testing requirements). Their current approach is to use the Demand management module in PPM to manage business requirement at business level and using the module in Quality Center to specify the requirements at technical level to translate them in test case. Nevertheless, HP does not have any Enterprise Architecture solution.