Many companies in their IT department have two units: IT Strategy & Planning and Enterprise Architecture. As regularly these are two different people managing these units, there is a high risk this ends up in serious conflicts.
The IT Strategist needs to understand the organization’s overall business strategy and is supposed to develop a comprehensive IT Strategic Plan that aligns with the business strategy (linkage, support of goals and objectives, etc.). He will continually assess all areas in the IT department to make sure their efforts and initiatives support this IT strategic plan, highlight gaps and identify alternatives to close gaps. During the development of the IT Strategic Plan (creation and maintenance of a detailed project plan (schedule, WBS, etc.) for the development and execution) , he interacts with various IT and Business Governance committees, and supports the execution and the evaluation of that plan.
How much is this different from one of the role of any Chief Enterprise Architect?
Among various roles the Chief Enterprise Architect ensures that the organization’s strategy is understood and acted on. Ideally, he should contribute to the strategy itself. He also has to understand, advocate and support the organization’s business and IT strategies.
Enterprise Architecture should be used to develop an IT Strategy. The EA team is in charge of implementing an EA program, which involves articulating the desired future state, understanding the current state, identifying the gaps between the two states and developing approaches to close these gaps. The team is leading the creation or evolution of the EA function or program, including the coordination of an appropriately balanced pursuit of enterprise business, information, application, technology and solution architecture viewpoints. Understand new technology future IT directions and how they can Impact the business.
When creating the new architecture (blueprint or high level architecture) which is based on the business goals and directions, they will identify new technology options and key finding from IT assets mapping and technology as-is mapping. The gap analysis will document each element that we mapped in the current state and translate this into roadmaps with dependencies and assignments: group gaps into projects, write one page of project high level analysis, assign resources to projects and creating a road map.
MODAF Acquisition Views will help to define these projects including dependencies.
FEAF in section 4 EA Transition Strategy / TOGAF Phases E (Opportunities and Solutions) and F (Migration Planning) describe similar activities.
Enterprise Architecture is a bridge to make the connection between business side planning and enterprise IT strategy making. When successful it delivers the IT strategy documentation.
The role of the IT Strategist should be split into two sets of activities (Enterprise Architecture and PMO (project management office) and does not make anymore sense when an organization has these two units.
Showing posts with label PPM. Show all posts
Showing posts with label PPM. Show all posts
21 May, 2009
TOGAF 9 Migration Planning and Project Portfolio Management
Phase F in TOGAF helps to describe how to create a viable implementation and migration plan in co-operation with the portfolio and project managers. Very often companies already have in place a Project Portfolio Management framework and there may be a need to integrate your enterprise architecture with that.
As an example, PMI has introduced a standard for Portfolio Management, and portfolio managers have a resource to help them develop professionally and achieve success for themselves and their enterprise. Within an organization, a portfolio represents a collection of active programs, projects and other work undertaken at a specific point in time to help the organization achieve strategic objectives. In essence, a portfolio reflects the priorities, investments and resource allocations.
Project Portfolio Management (PPM) may be part of an enterprise governance framework. It is a management process designed to help the organization-:
-To ensure that the organization is doing the "right things", optimally allocating scarce resources toward the enterprise’s objectives
-To acquire and view information about all projects
-To sort and prioritize each project according to certain criteria, such as strategic value, resource impact, cost, and so on.
PPM has several activities which are similar to the objectives of managing a financial portfolio:
-The identification of all the individual demands in the portfolio
-The development of a "big picture" view and a deeper understanding of the collection as a whole
-The sensible sorting, adding, and removing of items from the collection based on their costs, benefits, and alignment with long-term strategies or goals.
In a nutshell, Portfolio Management can help zero in on the projects that are most worth their effort; project management can help execute those projects most efficiently.
These activities can be perfectly integrated with Phase F of TOGAF. Once the work packages, projects and building blocks inventory is created, the enterprise architecture team with the portfolio managers (and other important stakeholders) will examine each project and prioritize it according to established criteria. They will probably assign a business value; conduct a cost business analysis for each project (done in collaboration with business people); identify the risks to the projects.
The overall list of projects is then considered to develop a well-balanced list of supported projects and provide an input for a detailed implementation and migration plan. It will also help to confirm the Transition Architecture defined in the phase E. The use of an Architecture definition increments table is highly recommended to list these projects.
Some projects will be given high priority and extensive support, some will be given moderate priority, and still others will be placed on hold or dropped entirely from the list. This will also help to finalize the Architecture roadmap. Finally, resources will need to be identified and made available.
Other Governance domains may also be to be integrated in the PPM process and Phase F, such as Risk Management (e.g. RiskIT), Project Management (e.g. PMI, PRINCE 2), etc.
Companies who are mature in Portfolio Management activities may integrate their existing work practices easily with TOGAF. This would enforce the relationship between the Enterprise Architecture team and the PMO (or the PPM team).
(You can also refer to another post: Why do we not find yet links between Enterprise Architecture and Project Portfolio Management? )
20 December, 2007
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:
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.
03 December, 2007
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.
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.
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.
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.
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.
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.
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.
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.
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.
These are restrictions on projects due to the budget or the time available to build a product or service.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.
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.
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.
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.
26 April, 2007
Enterprise Architecture Tools: Why are IBM, HP, Microsoft, CA and others absent?
Enterprise Architecture tools are often used to analyze and optimize the portfolio of business strategies, organizational structures, business processes, tasks and activities, information flows, applications, systems, and technology infrastructure.
Many of these tools have been designed with different architecture goals such as modeling, storing, managing and sharing information.
These tools can be classified in two main categories: EA repositories, EA-modeling suites (Business & IT) including some EA models.
Choosing a category depends mainly on the approach toward:
· EA top-to-bottom approach
· EA bottom-up approach
and the relationships with existing development and modeling tools.
Looking at the various acquisitions from big names these last years and the increasing interest in IT Governance, we observed several vendors trying to extend their tools portfolio going from modeling to service management, from project management to portfolio management.
IBM acquired in 2002 Holosofx, a business process modeling capabilities product to extend Web sphere Business Integration which then was re-branded to Websphere Business Modeler, a component for the modeling of a Business Architecture. CA acquired in 2005 Niku’s Project Portfolio Management (PPM). HP acquired in 2006 Mercury and Peregrine, companies having IT Service Management, Project Portfolio Management (PPM), and SOA Governance solutions.
Project Portfolio Management and Enterprise Architecture
PPM and Enterprise Architecture should be integrated in some way. All investments which support a Business strategy should be organized. A categorization model has to be used, followed by an evaluation and a prioritization. Once approved, the investments or demands become projects. But, how to decide when and how to make changes? How do we understand what can and can not be changed? What are the opportunities?
This is where the impact analysis and the “What if” scenarios enable to analyzethe company’s portfolio and assess the business contribution of each proposal, project, or application to an entire portfolio which needs also to be governed and managed.
An investment, a new demand should also be validated against an Enterprise Architecture. What are the impacts on the Business Architecture, the Business Processes? Does that make sense for a company to add new layers of information to an existing Information Architecture? In the context of a new solution, how does the new application affect the existing Application Architecture? Same thoughts apply on the technology architecture.
Very often Portfolio Management teams do not take into consideration these issues and may only focus on real-time visibility into resources, budgets, costs, programs, projects, and overall IT demand, but without considering impacts on the architecture.
Mature IT Governance would consider a strong interaction between a PPM team and an EA team. Once validated, an investment or a demand should be routed to the Enterprise Architecture team (can vary on the size and the scope), which add value to the first level evaluation. After a second level validation, the EA team using preferably an EA tool where specific architecture views and viewpoints have bee documented, is in a position to deliver recommendations to the PPM team.
We then go back to the company’s PPM process which adapts if necessary the budget, the costs, the resources and the program. There can be situations where the impact analysis detects side effects, or identify alternatives (may be for example the re-use of existing functions), or recommend to abandon the initiative.
Some companies which have implemented an automated process with a PPM solution would be tempted to also integrate the activities related to an Enterprise Architecture impact analysis.
Enterprise Architecture teams often use tools but rarely in an integrated way with the customer or other teams such as a PPM team. The kind of tools like Mega, Casewise, Metis-Troux technologies do not integrate yet with PPM solutions. Eventually we can consider an evolution in that direction from Telelogic which started a while ago to integrate Popkin with DOORS, the latest being maybe more a Demand Management solution than a PPM solution.
So now where are the IBM, HP, CA, and others?
Wouldn’t that make sense to use the Rational RequisitePro with Rational Portfolio Manager integrated with an EA Tool? Wouldn’t that make sense to have HP-Mercury ITG integrated with an EA Tool knowing that Systinet is an SOA governance platform and SOA surely linked to an EA program? Wouldn’t that make sense to have CA-Niku integrated with also an EA tool?
With all the small EA vendors proposing standalone products, there is a high chance that the “big names” will consider new acquisitions and the integration of EA solutions.
Many of these tools have been designed with different architecture goals such as modeling, storing, managing and sharing information.
These tools can be classified in two main categories: EA repositories, EA-modeling suites (Business & IT) including some EA models.
Choosing a category depends mainly on the approach toward:
· EA top-to-bottom approach
· EA bottom-up approach
and the relationships with existing development and modeling tools.
Looking at the various acquisitions from big names these last years and the increasing interest in IT Governance, we observed several vendors trying to extend their tools portfolio going from modeling to service management, from project management to portfolio management.
IBM acquired in 2002 Holosofx, a business process modeling capabilities product to extend Web sphere Business Integration which then was re-branded to Websphere Business Modeler, a component for the modeling of a Business Architecture. CA acquired in 2005 Niku’s Project Portfolio Management (PPM). HP acquired in 2006 Mercury and Peregrine, companies having IT Service Management, Project Portfolio Management (PPM), and SOA Governance solutions.
Project Portfolio Management and Enterprise Architecture
PPM and Enterprise Architecture should be integrated in some way. All investments which support a Business strategy should be organized. A categorization model has to be used, followed by an evaluation and a prioritization. Once approved, the investments or demands become projects. But, how to decide when and how to make changes? How do we understand what can and can not be changed? What are the opportunities?
This is where the impact analysis and the “What if” scenarios enable to analyzethe company’s portfolio and assess the business contribution of each proposal, project, or application to an entire portfolio which needs also to be governed and managed.
An investment, a new demand should also be validated against an Enterprise Architecture. What are the impacts on the Business Architecture, the Business Processes? Does that make sense for a company to add new layers of information to an existing Information Architecture? In the context of a new solution, how does the new application affect the existing Application Architecture? Same thoughts apply on the technology architecture.
Very often Portfolio Management teams do not take into consideration these issues and may only focus on real-time visibility into resources, budgets, costs, programs, projects, and overall IT demand, but without considering impacts on the architecture.
Mature IT Governance would consider a strong interaction between a PPM team and an EA team. Once validated, an investment or a demand should be routed to the Enterprise Architecture team (can vary on the size and the scope), which add value to the first level evaluation. After a second level validation, the EA team using preferably an EA tool where specific architecture views and viewpoints have bee documented, is in a position to deliver recommendations to the PPM team.
We then go back to the company’s PPM process which adapts if necessary the budget, the costs, the resources and the program. There can be situations where the impact analysis detects side effects, or identify alternatives (may be for example the re-use of existing functions), or recommend to abandon the initiative.
Some companies which have implemented an automated process with a PPM solution would be tempted to also integrate the activities related to an Enterprise Architecture impact analysis.
Enterprise Architecture teams often use tools but rarely in an integrated way with the customer or other teams such as a PPM team. The kind of tools like Mega, Casewise, Metis-Troux technologies do not integrate yet with PPM solutions. Eventually we can consider an evolution in that direction from Telelogic which started a while ago to integrate Popkin with DOORS, the latest being maybe more a Demand Management solution than a PPM solution.
So now where are the IBM, HP, CA, and others?
Wouldn’t that make sense to use the Rational RequisitePro with Rational Portfolio Manager integrated with an EA Tool? Wouldn’t that make sense to have HP-Mercury ITG integrated with an EA Tool knowing that Systinet is an SOA governance platform and SOA surely linked to an EA program? Wouldn’t that make sense to have CA-Niku integrated with also an EA tool?
With all the small EA vendors proposing standalone products, there is a high chance that the “big names” will consider new acquisitions and the integration of EA solutions.
11 April, 2007
13ème Congrès Romand du Management de Projet
Atelier 11 : La gestion de projet et ITIL : deux mondes opposés, complémentaires ou intégrés ? présenté par itSMF (Serge Thorn)
Jeudi 12 avril – 11h20 à 12h00
Complémentarité des processus de Project management et de Service management :
• Intégration de la gestion de projet dans une logique de "Gestion des changements"
• Intégration du recueil des besoins dans le Service Level Management
• Impact de la gestion de la demande sur le Portfolio management
• Comparatif des processus de prise de décision et de la gestion des risques.
Jeudi 12 avril – 11h20 à 12h00
Complémentarité des processus de Project management et de Service management :
• Intégration de la gestion de projet dans une logique de "Gestion des changements"
• Intégration du recueil des besoins dans le Service Level Management
• Impact de la gestion de la demande sur le Portfolio management
• Comparatif des processus de prise de décision et de la gestion des risques.
28 March, 2007
Achieving IT Operational Excelllence
You may be interested in an article I wrote for a magazine: Pharma Focus Asia Issue 4 2007 titled :
Operational Excellence: IT governance, Enterprise Architecture and service management, which explains what are the components of such a program in my company.
The article will soon be downloadable from http://www.pharmafocusasia.com/magazine/ (issue 4), but I'm copying its content:
IT governance defines a structure of relationships, processes and measures to direct and control IT in order to achieve the enterprise's goals.
IT governance is currently a key topic for many IT functions. Its definition varies very often, but key themes remain essential for all companies: effectiveness, efficiency and reliability. Business value and risk mitigation are also at the centre of this domain. It represents a significant part of enterprise governance, and due to the horizontal nature of IT, wherein almost everyone in the enterpriseuses IT assets to complete their responsibilities, the impact of effective IT governance is most visible.
IT governance defines a structure of relationships, processes and measures to direct and control IT assets (e.g. people, finance, infrastructure) in order to achieve the enterprise's goals by adding value while balancing risk with return. It helps to define roles and responsibilities and specify accountability framework to encourage desirable behaviour in IT and accountability for the use of IT assets. ITgovernance also helps to standardise best practices and define monitoring methods.
For XXXXX International SA, IT governance has always been the responsibility of the IT management team, being an integral part of XXXXX's governance, and consists of the leadership and organisational structures and processes that ensure that the IT function sustains and extends the company’s strategies and objectives to deliver value. IT does this within acceptable risk boundarieswhile taking into account culture, organisational structure and maturity.
For the XXXXX IT function, IT governance ensures that delivery expectations are fulfilled, IT resource deployment is continuously planned, targeted and optimised while IT performance is measurable and that the risks are minimised.Among the various components of an IT governance framework, the following domains were retained as being key themes to reach a high level of quality and excellence through continuous improvement:
• Quality management
• Balance scorecard
• Risk management
• Skills management
• Project and portfolio management
• Service management
• Enterprise Architecture
• Information security management
• Audit management
• IT performance and value management
Quality management was initially the main focus for IT, and since 1999, has been certified worldwide in ISO 9001. For the last two years, quality management has also included risk management(identifying risks from strategy down to operations and providing mitigation) as well as skills management (ensuring that the staff in the IT function have the appropriate skills in line with the strategy).Since 2001, IT measures its business alignment, which is highly integrated within the business strategy, using the IT balance scorecard tool. For more than three years, service management and IT Infrastructure Library (ITIL) have been the drivers to improve the quality of services for the end users. XXXXX's IT function deployed the ITIL processes covering both service support and service delivery. Thepurpose of this initiative was to:
• Increase customer satisfaction with IT
• Enhance communication with clients
• Achieve higher reliability in missioncritical systems and infrastructure
• Improve the cost-benefit of services
• Create a “common sense” among staff
These processes are mostly supported by tools from HP-Peregrine and IBM Tivoli. Project management has always been a key practice for IT people. Based on a traditional System Development Life Cycle (SDLC), the methodology has been widely used by the IT function for manyyears. All projects have to comply with documentation, templates and checkpoints where project progress is monitored.Committees validate the various steps of the methodology and give their approval to move to the next phase.
Portfolio management is known internally as the “Funnel”. The portfolio governance process starts when a business user requests or suggests a new capability. The request is automatically routed to aninformation manager (internal relationship manager), then to a business analyst or team for an initial business case before being routed to the IT management committee for review and scoring. The ITmanagement team then evaluates the prioritised, ranked projects to determine the proper portfolio mix and whether to accept the recent request. The “Funnel” is:
• A categorisation model
• A common language for business and IT to:
> Support business strategy
> Organise investments
> Evaluate and prioritise IT projects
> Govern and manage applications portfolio
> Decide when and how to make changes
> Understand what can and cannot be changed
> Provide real-time visibility into resources, budgets, costs, programmes, projects, and overall IT demand
• An input to the IT strategic planSolutions from HP-Mercury help XXXXX to support both project and portfolio management. An Enterprise Architecture (EA) consists of the vision, principles, standards and processes thatguide the purchase, design and deployment of technology within an enterprise. EA describes the interrelationships between business processes, information, applications and underlying infrastructurefor that enterprise, and provides best practices for technology purchase, design and deployment. EA structures and processes govern adherence to an organisation’s technology strategy and provide amanaged environment for the use of new technology.
Enterprise Architecture
• Allows alignment with the company’s business model and strategy
• Enables business changes, technologically based business opportunities
• Easier introduction of new technologies
• Allows standardisation
• Drives information/data consolidation
• Reduces enterprise-application integration complexity
• Facilitates outsourcing as appropriate
• Utilises assets more efficiently
• Provides the facility to better assess the impact of changes
• Ultimately, reduces time to market
Architecture governance is essentially a control or series of controls in the development process which is efficient when supported by good documentation (principles, guidelines, standards) and communicated effectively. To build such an Enterprise Architecture, XXXXX considered the use of both the Zachman and the Open Group TOGAF’s frameworks. Such a programme requires solid processes with ownership and accountability.
Enterprise Architecture is a component of IT governance which interacts with most of the other frameworks such as project and portfolio management, quality, maturity and security management. To manage EA, the company decided to use the Metis-Troux technologies solution.
Security management is another component of the IT governance programme, covering both information security and technical security. The BS 7799 certification was obtained in 2005 for GenevaHQ and ISO 27001 obtained on a worldwide basis in 2006. At the beginning of 2006, a new position reporting directly to the CIO was created to further develop IT performance and value management. Keydrivers for this are: optimising IT value, demonstrating IT value as a critical component of business processes, improving the quality of IT value measurement and reporting and becoming a potentialsource of innovation.
Performance management is not a stand-alone initiative; it is a process that needs to be established and fully integrated in strategic alignment with the business, value delivery and company performancemanagement. This performance framework consistently ensures that IT:
1. Is adding business value to the corporation
2. Is meeting the real customers’ real needs
3. Is running well as a business
Control Objectives for Information and related Technology (COBIT) provides a set of best practices and tools for auditing IT processes and assessing standards compliance, maturity and associatedrisks. COBIT can be associated to other frameworks, as architecture can be audited with certain KPIs.
In the frame of an IT research and innovation initiative, CMMi has been under evaluation. It is the Capability Maturity Model Integration which has been developed by the Carnegie MellonUniversity – Software Engineering Institute, a suite of products used for process improvement. It consists of best practices that address the development and maintenance of products and services covering the product life cycle from conception through delivery and maintenance.
CCMi models could be used in conjunction with all XXXXXs IT processes found in service management(ITIL), COBIT, project management (SDLC/Prince), Enterprise Architecture (Zachman-TOGAF), quality (ISO 9001), security management (ISO 27001), but the programme has not yet been considered.IT governance at XXXXX encompasses many disciplines within the organisation including IT strategy, risk management, IT service management and compliance management to name a few. Understandably, this presents a significant challenge for companies seeking to identify a starting point for their IT governance initiative. Fortunately, best practice governance guidelines and procedures do exist within the industry. Firms, moving ahead with the adoption of a standard will be well served to utilise a phased implementation project approach and start with elements of the standard that will yield their organisation the most benefits—
• Optimised IT strategy and execution
• Improve resource utilisation
• Improve planning and resourcing
• Risk assessment
• Real-time management reporting
In 2005, a benchmark with KPMG positioned XXXXX’s IT as number one among 119 other companies in the life sciences industry. In 2006, the number one position was maintained while thenumber of organisations increased to 125. This recognition states that the IT functionis using IT best practices to support the business and that XXXXX IT controls can now be classed as “excellent”.This was driven by major improvements in the areas of IT operations (incident, problem, operation, and configuration management), security (ISO27001), control assurance (risk, audit, planning management)and Sarbanes Oxley (SOX).
23 January, 2007
Are there any relationship between Demand Management, Requirement Management, Request Management and Change Management?
In the context of IT, Demand Management is a process which manages the complex and strategic IT demand requests issued by the business. In this process we prioritize, consolidate, schedule the requests, enabling the business users and IT to collaborate efficiently at every step, cutting costs and accelerating resolution. Normally, this is an activity belonging to Portfolio Management which is the the process of determining (and monitoring) how much money the enterprise should spend on the various categories of IT-enabled business investments. Demand Management works with both business and its IT peers through an ongoing and iterative process that aggregates demand for IT services, represents the resources requested and their costs to the business, and helps optimize the deployment of IT resources over time. Demand Management is often covered by Portfolio Management solutions or Request Management solutions.
A few examples are Mercury ITG, Clarity (Niku) from CA, Compuware Changepoint and Borland Tempo.
These suites are more in the PPM market than anything else and these vendors should be considering to link PPM suites with IT Service Management suites for several reasons.
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.
Solutions such as RequisitePro from IBM and Telelogic Doors support that process.
Here we see in some way some identical concepts with Demand Management and potential links also with IT Servie Management.
But let’s still define two additional concepts.
ITIL doesn't have a separate process for Request Management as it does, for instance, with Incident Management in version 2. The Request Management will manage (from request to fulfillment) the goods and services requested by users based on the catalog provided. Standardized goods and services can be made available to the end users through self-service interface or by calling the Service Desk. When handling the request the Request Management will also refer to the SLA.. Version 3 should clarify the situation and define a new process, where Service Requests are now a function of Request Management which ties on the Change Management process (In version 2, Service Requests were a part of the 'Incident Mangement' life cycle).
The Change Management process ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to minimize the impact of change-related incidents and improve day-to-day operations. Changes are issued either from Incidents, Problems or customer’s requests. There are also touch points between Project Management and Change Management.
Finally and to keep it very simple, everything is about a user asking something to an IT department, with different levels of importance. From a new product to a new service, from a additional or new feature to a physical piece of hardware, allowing the business to be more efficient.
There should be a clear alignment of these concepts with an end to end process, integrating IT Service Management at the end. All demands should end up in the ITIL Change Management process and vendors should integrate their platforms to facilitate that integration.
A few examples are Mercury ITG, Clarity (Niku) from CA, Compuware Changepoint and Borland Tempo.
These suites are more in the PPM market than anything else and these vendors should be considering to link PPM suites with IT Service Management suites for several reasons.
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.
Solutions such as RequisitePro from IBM and Telelogic Doors support that process.
Here we see in some way some identical concepts with Demand Management and potential links also with IT Servie Management.
But let’s still define two additional concepts.
ITIL doesn't have a separate process for Request Management as it does, for instance, with Incident Management in version 2. The Request Management will manage (from request to fulfillment) the goods and services requested by users based on the catalog provided. Standardized goods and services can be made available to the end users through self-service interface or by calling the Service Desk. When handling the request the Request Management will also refer to the SLA.. Version 3 should clarify the situation and define a new process, where Service Requests are now a function of Request Management which ties on the Change Management process (In version 2, Service Requests were a part of the 'Incident Mangement' life cycle).
The Change Management process ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to minimize the impact of change-related incidents and improve day-to-day operations. Changes are issued either from Incidents, Problems or customer’s requests. There are also touch points between Project Management and Change Management.
Finally and to keep it very simple, everything is about a user asking something to an IT department, with different levels of importance. From a new product to a new service, from a additional or new feature to a physical piece of hardware, allowing the business to be more efficient.
There should be a clear alignment of these concepts with an end to end process, integrating IT Service Management at the end. All demands should end up in the ITIL Change Management process and vendors should integrate their platforms to facilitate that integration.
23 November, 2006
Does an IT ERP make sense?
Despite the fact that some software vendors companies such as ITM Software are considered to deliver such a solution, I would rather qualify this product as a Project and Portfolio Management solution such as Primavera, Artemis, Mercury and others.
Many companies have a wide range of non integrated solutions covering several aspects of IT Governance such as:
-Project Management
-Portfolio Management
-Time Management
-Service Management
-Enterprise Architecture
-System Management
-Security Management
-Asset Management
etc..
For each of these components some of them have associated processes but no real touch points between them and the visibility is quite difficult to get in terms of IT Service quality. Some companies passed certifications such as ISO 9000, ISO 27001, went through COBIT, and are ITIL based etc... But from my various observations, they do not have a consolidated or integrated view of their IT Services which would contribute to the improvement of Business IT Alignment.
Very often, top management including the CIO ask for IT to deliver Dashboards where we can have in real time indicators (KPIs) on the department performance and then be able to benchmark against competition.
Among existing solutions we have, IT Governance suites such as Mercury ITG or CA Clarity, Service Management platforms such as Peregrine Service Desk, Remedy, CA, HP, Asset management solutions, and finally Time Management product. In the system management landscape, Tivoli, CA Unicenter, and lots of various monitor solutions to manage networks. Fiinally, Enterprise Architecure is often covered by companies such as Telelogic (Popkin), Casewise, Metis solutions etc…
My experience would be to claim that first we need to re-engineer the process, have integrated flows between domains in order ro be able deliver these dashboards, finally avoid duplicated activities within an IT Department.
As no vendors today is able to deliver such an “IT ERP” (but probably HP, IBM and CA will be able to deliver this but nor before a couple of years…), an alternative would be to consider services around these platforms and then from a portal, orchestrate those services, provide results in various dashboards. Obviously if we had an integrated platform, that would be easier.
For the time being, mash-up applications are probably the only way to produce an IT ERP.
Many companies have a wide range of non integrated solutions covering several aspects of IT Governance such as:
-Project Management
-Portfolio Management
-Time Management
-Service Management
-Enterprise Architecture
-System Management
-Security Management
-Asset Management
etc..
For each of these components some of them have associated processes but no real touch points between them and the visibility is quite difficult to get in terms of IT Service quality. Some companies passed certifications such as ISO 9000, ISO 27001, went through COBIT, and are ITIL based etc... But from my various observations, they do not have a consolidated or integrated view of their IT Services which would contribute to the improvement of Business IT Alignment.
Very often, top management including the CIO ask for IT to deliver Dashboards where we can have in real time indicators (KPIs) on the department performance and then be able to benchmark against competition.
Among existing solutions we have, IT Governance suites such as Mercury ITG or CA Clarity, Service Management platforms such as Peregrine Service Desk, Remedy, CA, HP, Asset management solutions, and finally Time Management product. In the system management landscape, Tivoli, CA Unicenter, and lots of various monitor solutions to manage networks. Fiinally, Enterprise Architecure is often covered by companies such as Telelogic (Popkin), Casewise, Metis solutions etc…
My experience would be to claim that first we need to re-engineer the process, have integrated flows between domains in order ro be able deliver these dashboards, finally avoid duplicated activities within an IT Department.
As no vendors today is able to deliver such an “IT ERP” (but probably HP, IBM and CA will be able to deliver this but nor before a couple of years…), an alternative would be to consider services around these platforms and then from a portal, orchestrate those services, provide results in various dashboards. Obviously if we had an integrated platform, that would be easier.
For the time being, mash-up applications are probably the only way to produce an IT ERP.
07 November, 2006
Why do we not find yet links between Enterprise Architecture and Project Portfolio Management?
A Project Portfolio Management governance process should start when a business user requests or suggests a new capability. The request is automatically routed to a gatekeeper, then to a business analyst or team for an initial business case before being routed to the operations council and the architecture standards committee for review and scoring.
The business team then evaluates the prioritized, ranked projects to determine the proper portfolio mix and whether to accept the recent request.
Project Portfolio Management is:
• A categorization model
• A common language for business and IT to …
• Support Business strategy
• Organize investments
• Evaluate and prioritize IT projects
• Govern and manage applications portfolio
• Decide when and how to make changes (opportunities)
• Understand what can and can not be changed
• Provide real-time visibility into resources, budgets, costs, programs,
projects, and overall IT demand
• A hedge
• “What if” scenarios enable us to analyze
the portfolio and assess the business
contribution of each proposal, project,
or application to the entire portfolio
• Triggers, Thresholds
The Enterprise Architecture steering committee should be part of this governance process and be able to measure the impact at various level of the architecture:
- What is in the impact in terms of Business Procee
- What is the impact at the information level
- What is the impact at the application level
- And finally what is the impact on the technology
Assuming that a company has an Enterprise Architecture in place and an associated governance, the PPM process should be linked to the first one.
None of the existing solutions related to PPM have considered yet this type of integration. On one side we do have PPM tools such as Mercury ITG (now HP), CA Clarity Niku and on the other side EA platforms such as Mega, Casewise, and Telelogic (Doors can be considered as some sort of Demand/Requirement Management solution but can not be considered as a PPM) among others.
I’m still wondering why a company such as HP has not yet been considering an EA tool integrated with their future PPM product, or even IBM which has a PPM product with rationale but no EA solution neither.
There is a high change that the next wave of acquisition after Service Management and SOA platforms will be Enterprise Architecture tools as this would make sense to deliver a full IT ERP.
The business team then evaluates the prioritized, ranked projects to determine the proper portfolio mix and whether to accept the recent request.
Project Portfolio Management is:
• A categorization model
• A common language for business and IT to …
• Support Business strategy
• Organize investments
• Evaluate and prioritize IT projects
• Govern and manage applications portfolio
• Decide when and how to make changes (opportunities)
• Understand what can and can not be changed
• Provide real-time visibility into resources, budgets, costs, programs,
projects, and overall IT demand
• A hedge
• “What if” scenarios enable us to analyze
the portfolio and assess the business
contribution of each proposal, project,
or application to the entire portfolio
• Triggers, Thresholds
The Enterprise Architecture steering committee should be part of this governance process and be able to measure the impact at various level of the architecture:
- What is in the impact in terms of Business Procee
- What is the impact at the information level
- What is the impact at the application level
- And finally what is the impact on the technology
Assuming that a company has an Enterprise Architecture in place and an associated governance, the PPM process should be linked to the first one.
None of the existing solutions related to PPM have considered yet this type of integration. On one side we do have PPM tools such as Mercury ITG (now HP), CA Clarity Niku and on the other side EA platforms such as Mega, Casewise, and Telelogic (Doors can be considered as some sort of Demand/Requirement Management solution but can not be considered as a PPM) among others.
I’m still wondering why a company such as HP has not yet been considering an EA tool integrated with their future PPM product, or even IBM which has a PPM product with rationale but no EA solution neither.
There is a high change that the next wave of acquisition after Service Management and SOA platforms will be Enterprise Architecture tools as this would make sense to deliver a full IT ERP.
05 September, 2006
The art (and difficulty) of selecting an IT Governance Framework
IT Governance is one of those concepts that everyone is talking about.
Many companies after having selected a set of IT Governance pillars are looking for solutions to support them and deliver several types of dashboard to either the Corporate and/or IT Management. But, what are these pillars? Some IT department considers one or more components as IT Governance, some other cumulates several components.
IT Managers very often refer to ITIL, or COBIT, or Balance Scorecards or any other frameworks which will improve efficiency and give some visibility to the business.
Let me briefly describe first what I’m considering as components of an IT Governance, but prior to that, I would like to refer to a very simple definition from the Harvard Business School:
“We define IT Governance as specifying the decision rights and accountability framework to encourage desirable behavior in IT”
Fundamentally, IT Governance is concerned about two main things: IT’s delivery of value to the business and mitigation of IT risks.
The components of IT Governance can or should include at least:
- Aligning IT strategy with the business strategy
- Quality Management
- Strategic IT Planning
- Enterprise Architecture
- Project and Portfolio Management (PPM)
- Service Management
- Audit Management
- Security Management
- Risk Management
- Performance Measurement
The list is not exhaustive and could obviously be completed.
I tried to find if there were any IT Governance frameworks available in the market and always ended with specific frameworks related to the components of this IT Governance. ITIL, COBIT, ISO 9000, CMMi and others… Now, from there, where do I start?
What we need is a Framework of Frameworks… where I know where to start, where to pursue, where to end…all of that in an iterative mode..
I recently discovered The Calder-Moir IT Governance Framework http://www.itgovernance.co.uk/page.framework which looks like as a good initiative in terms of standards framing. This has been developed by IT Governance Limited.
Until today, to my knowledge, no single organization has provided a full picture of how to manage IT Governance. Is this framework something which should be seriously be considered or only a way to sell consultancy?
Many companies after having selected a set of IT Governance pillars are looking for solutions to support them and deliver several types of dashboard to either the Corporate and/or IT Management. But, what are these pillars? Some IT department considers one or more components as IT Governance, some other cumulates several components.
IT Managers very often refer to ITIL, or COBIT, or Balance Scorecards or any other frameworks which will improve efficiency and give some visibility to the business.
Let me briefly describe first what I’m considering as components of an IT Governance, but prior to that, I would like to refer to a very simple definition from the Harvard Business School:
“We define IT Governance as specifying the decision rights and accountability framework to encourage desirable behavior in IT”
Fundamentally, IT Governance is concerned about two main things: IT’s delivery of value to the business and mitigation of IT risks.
The components of IT Governance can or should include at least:
- Aligning IT strategy with the business strategy
- Quality Management
- Strategic IT Planning
- Enterprise Architecture
- Project and Portfolio Management (PPM)
- Service Management
- Audit Management
- Security Management
- Risk Management
- Performance Measurement
The list is not exhaustive and could obviously be completed.
I tried to find if there were any IT Governance frameworks available in the market and always ended with specific frameworks related to the components of this IT Governance. ITIL, COBIT, ISO 9000, CMMi and others… Now, from there, where do I start?
What we need is a Framework of Frameworks… where I know where to start, where to pursue, where to end…all of that in an iterative mode..
I recently discovered The Calder-Moir IT Governance Framework http://www.itgovernance.co.uk/page.framework which looks like as a good initiative in terms of standards framing. This has been developed by IT Governance Limited.
Until today, to my knowledge, no single organization has provided a full picture of how to manage IT Governance. Is this framework something which should be seriously be considered or only a way to sell consultancy?
Subscribe to:
Comments (Atom)
