1. THE IMPACT OF
ENTERPRISE ARCHITECTURE SERVICES ON
SELECTING IT PROJECTS
Master Thesis IMSE
Student:
S. Chandramouli
ANR 107208
S.Chandramouli@uvt.nl
Supervisor:
Dr. M. T. Smits – Tilburg University
m.t.smits@uvt.nl
Second Reader:
Dr. Kostas Magoutis - University of Crete
magoutis@ics.forth.gr
Third Reader:
Prof. Dr. Bernhard Mitschang - Universität Stuttgart
Bernhard.Mitschang@ipvs.uni-stuttgart.de

3. Acknowledgements
I would never have been able to finish my thesis without the guidance of my supervisors, help from
friends, and support from my parents and sister.
I would like to express my deepest gratitude to my supervising professor, Dr. M.T.Smits, for his excellent
guidance, support and patience, providing me with an a great opportunity for doing research.
I would like to thank Mr. Vahid Kharidar, who was an excellent mentor as well as a great friend, actively
encouraging me to participate in the project in Philips, who gave me enough freedom to experiment with
new ideas related to design, and a lot of autonomy in decision making.
I am highly indebted to Tilburg University and the Erasmus Mundus Association for providing me the
prestigious scholarship to pursue the IMSE Master Programme.
Finally, I would like to thank all the inmates of Raiffeisenstraat 7, who were always there cheering me up
and stood by me through the good times and bad.

4. 2
Abstract
Although Project Portfolio Management techniques have been existent for more than thirty years, the
idea of the Business and IT seamlessly working together in any organization still remains a horrifying
challenge. Most Business users submit their requests to IT and then, they have no idea what happens next.
The IT organizations face problems of their own with too many disconnected systems, highly localized
processes and complex technologies. This makes it virtually impossible for IT to understand the demands
it faces, and the frequency of reviewing demands tends to become every low leading to new business
demands just sitting in IT for almost a year. The Business users on the other hand face difficulties in
deploying efficient Portfolio Management processes due to reasons like manual approval processes,
inability to track demands due to limited visibility and highly complicated PPM tools.
The research goal of this paper is to determine the impact of developing an integrated set of Enterprise
Architecture services on selecting and allocating budgets for IT projects. The paper first investigates the
several challenges faced by Philips Lighting in ensuring a smooth flow of business demands to obtain
budget allocation ensuring project execution. Then, a new Portfolio Management methodology
comprising of Enterprise Architecture services is proposed, designed, developed and deployed to ensure
accurate translation of business demands into IT projects. Finally, the new model is validated to
ascertain the extent to which the problems faced in the previous method are overcome or minimized.

5. TABLE OF CONTENTS
Abstract...........................................................................................................................2
1 INTRODUCTION .....................................................................................3
1.1 Research Problem:................................................................................................3
1.2 Research Goal: .....................................................................................................3
1.3 Research Question:...............................................................................................4
1.4 Research Methodology:........................................................................................4
1.5 Structure of Thesis: ..............................................................................................6
2 LITERATURE REVIEW ..........................................................................7
2.1 What are Enterprise Architecture Services?.........................................................7
2.2 Portfolio Management in Philips Lighting.........................................................13
2.3 How can Enterprise Architecture services be designed and developed?............16
2.4 How does the development of EA Services impact Portfolio Management?.....19
3 DESIGN AND DEVELOPMENT ..........................................................21
3.1 Baseline Architecture: Portfolio Management in Philips until Dec 2011 ..........21
3.2 Target Architecture : New Portfolio Management method from Jan 2012........23
3.3 Constraints:.........................................................................................................38
4 COMMUNICATION & VALIDATION ................................................39
4.1 Communication ..................................................................................................39
4.2 Validation...........................................................................................................40
5 CONCLUSION & FUTURE WORK......................................................47
5.1 Answers to Research Question...........................................................................47
5.2 Assumptions and Limitations.............................................................................48
5.3 Suggestions for Future Research........................................................................49
REFERENCES ...........................................................................................................51
APPENDIX A - INTERVIEWS ................................................................................53
APPENDIX B – PHILIPS LIGHTING ORGANIZATION CHART....................54

6. 2
TABLE OF FIGURES
Figure 1 - Research Question........................................................................................................................4
Figure 2 - Research Methodology.................................................................................................................5
Figure 3 - EA Stakeholder Matrix.................................................................................................................8
Figure 4 - Organizational Model for EA.....................................................................................................10
Figure 5 - PPM Process in "swinlane" format (Pennypacker, et al. -2009) ................................................12
Figure 6 - Project Management in Philips ..................................................................................................13
Figure 7 - Philips PPM Overview...............................................................................................................15
Figure 8 - EA Alignment Cycle (P. Harmon, 2003) ...................................................................................17
Figure 9 - TOGAF ADM model .................................................................................................................18
Figure 10 - Detecon's Architecture Process (Detecon 2005) ......................................................................20
Figure 11 - Baseline Business Architecture: Philips PPM..........................................................................22
Figure 12 - Baseline Technology Architecture: Philips PPM.....................................................................23
Figure 13 - Proposed PPM solution............................................................................................................24
Figure 14 - New IT Operating Model, Philips............................................................................................25
Figure 15 - Data Architecture (TO BE) ......................................................................................................30
Figure 16 - Sharepoint Selection, Source: Philips High Level Document..................................................31
Figure 17 - Nintex Workflow Designer ......................................................................................................33
Figure 18 - PPM Tool Home Page..............................................................................................................34
Figure 19 - Demand Status Tracking..........................................................................................................35
Figure 20 - Portfolio Risk Analysis ............................................................................................................36
Figure 21 - Throughput time.......................................................................................................................37
Figure 22 - Project Initiation in 2010..........................................................................................................42
Figure 23 – Business Case Risk Analysis...................................................................................................44
Figure 24 - Project Financials.....................................................................................................................44
Figure 25 - Conclusion................................................................................................................................48
Figure 26 - Clarity Integration ....................................................................................................................50

7. 3
1 Introduction
1.1 Research Problem:
Modern Project Portfolio Management literature was first introduced as early as 1981 (McFarlan 1981),
which paved the way for adaption of PPM techniques to IT Projects. “Portfolio management (PM)
techniques are systematic ways of looking at a set of projects or activities or even business units, in order
to reach an optimum balance between risks and returns, stability and growth, attractions and drawbacks
in general, by making the best use of usually limited resources” (Tidd, et al. 2005).
There are several challenges faced by companies today in ensuring a smooth flow of business demands
throughout IT portfolio for project execution (Cooper, et al. 2000) (M. Tam 2012). While some of the
challenges can be dealt with by “doing projects right” namely Project Management, most of them are to
do with “doing the right projects” which is Portfolio Management (De Reyck, et al. 2005).
The Philips Lighting IT organization runs three services, which are not completely formalized, not
integrated and poorly aligned with each other.
 Stakeholder Relationship Management
 Demand Management
 IT Portfolio Management
The current problem is that these services are not integrated at all. The reasons causing the current
problems in each service are explained in detail in Chapter 3.
In October 2011, Philips introduced the Accelerate initiative, which is a Philips worldwide performance
and change management program aimed at unlocking their potential by helping them to deliver on their
strategy faster. The changes as defined in the Accelerate journey are being driven through five key
initiatives: Customer Centricity, Resource to Win, End2End, Operating Model and Culture Change. With
regard to Portfolio Management, the goal is to ensure that every business has a single point of contact (IT
Business Partner) towards IT function who can support and translate business objectives into IT priorities,
initiatives and services.
This thesis will investigate how the new operating model can be applied to Project Portfolio Management
Processes by the application of relevant Enterprise Architecture Services, in order to answer the following
Research Question.
1.2 Research Goal:
To propose, design, deploy and validate an integrated set of services for the ‘Project Portfolio
Management’ processes to ensure accurate translation of business demands into IT projects that fit
company architectural requirements and business needs.

8. 4
1.3 Research Question:
How does the development of a specific set of Enterprise Architecture Services influence / impact
the selection of IT Projects (Project Portfolio Management) in Philips Lighting?
Figure 1 - Research Question
Related Questions:
1. How are IT Projects allocated budgets in the current scenario? What are the processes and who
are the actors involved? What are the various reasons for the problems stated in 1.1?
2. What is the relationship between the Stakeholder Relationship Management Service, Demand
Management Service and the IT Portfolio Management Service?
3. How could an integrated ‘Project Portfolio Management’ Architecture be designed matching the
above mentioned three independent services?
1.4 Research Methodology:
The research methodology used here is that of the Information Systems Design Science Research
(Hevner, et al. 2004), where the new ‘integrated set of services’ is considered as the design artifact. The
following figure illustrates the research design in order to answer the Research Question stated above.
To begin with, a Literature Review of the IT Project Portfolio Management within Philips Lighting was
carried out to obtain an overview of the entire process – right from the moment an idea is introduced until
the project is approved and the budget is allocated. Then an analysis of the ‘As Is’ process was carried out
by studying the End Project Reports of certain Projects executed in the last one year (Philips Intranet).

9. 5
Figure 2 - Research Methodology

10. 6
The next stage was the complete design of the ‘To Be’ PPM Process based on the High Level Document
provided by Philips Lighting, and by conducting interviews with the concerned IT Business Partners. The
Enterprise Architecture TOGAF ADM methodology was used to design and deploy the integrated set of
services in MS Sharepoint 2010, using Nintex Workflow 2010 for the related Workflow and Approval
Processes.
The final stage was the Monitoring, Validation and Evaluation of the new PPM Process after rolling out
the new tool to the end users. The Design Evaluation methods were both Observational and Experimental.
While the monitoring was done with the help of defined KPIs, the evaluation and validation was done by
conducting interviews with personnel across different Sectors as well as through surveys.
1.5 Structure of Thesis:
The basic design of the research question is illustrated in Figure 1, and the overall structure of this Thesis
is organized in the forthcoming chapters as follows.
Chapter 2 provides a detailed literature review about Enterprise Architecture and the three services
namely Stakeholder Relationship Management, Demand Management and Project Portfolio Management,
following which the Portfolio Management process in Philips Lighting is discussed. Then the Enterprise
Architecture Development Method is explained, and finally the description of how Enterprise
Architecture can influence Portfolio Management decisions.
In Chapter 3, the baseline and target architectures based on the TOGAF framework is explained – the
Baseline Architecture being the previous method used at Philips Lighting for project selection, and the
Target Architecture being the proposed solution based on the Enterprise Architecture services.
The communication of the newly deployed model to the respective users, and its validation are described
in Chapter 4. A detailed analysis is provided about the steps a project underwent in obtaining budget prior
to the introduction of the new method, and the several difficulties that arose in doing so. Then, two
projects that were selected and allocated budget based on the new method are analyzed, and the aspects
on which the problems faced in the old method are overcome are seen.
Finally, Chapter 5 concludes the paper outlining how far we have come since the definition of the
research question, and the assumptions and limitations in doing so. It then talks about the areas where
there is scope for improvement, providing recommendations to suggestions for future research.

11. 7
2 Literature Review
2.1 What are Enterprise Architecture Services?
2.1.1 What is Enterprise Architecture?
Enterprise Architecture is defined as the description of an enterprise as a system in terms of its
components, their inter-relationships, and the principles and guidelines governing the design and its
evolution. The description is usually done to identify gaps between the current state and a desired future
state. Enterprise Architecture is often described at multiple levels of breadth and depth, and enables
effective execution of an organization's strategy. IT Architecture is a major enabling component of an
Enterprise Architecture (Architecting The Enterprise 2012).
Although many enterprise-architectural methodologies have come and gone since the 1990s, at this point,
perhaps ninety percent of the field use one of these four methodologies: (R. Sessions, 2007)
 The Zachman Framework for Enterprise Architectures
 The Open Group Architectural Framework (TOGAF)
 The Federal Enterprise Architecture
 The Gartner Methodology
While the Zachman Framework is actually more accurately defined as a taxonomy for Enterprise
Architectures, the TOGAF is actually more accurately defined as a process. The Federal Enterprise
Architecture can be viewed either as a proscriptive methodology for creating an enterprise architecture or
an implemented enterprise architecture, while the Gartner Methodology is best described as an enterprise
architectural practice.
(R. Sessions, 2007) outlines the various criteria based on which the four Enterprise Architecture
frameworks have been rated. Although not all of these criteria might be relevant to an organization, some
might be more important than others. Based on these 12 criteria that are used for comparing and
evaluating the above four enterprise-architectural methodologies in (R. Sessions, 2007), the TOGAF
framework is chosen as the most suited for the purpose of this thesis.
EA Function:
According to (Raadt, et al. 2008), the Enterprise Architecture Function is defined as: “The organizational
functions, roles and bodies involved with creating, maintaining, ratifying, enforcing, and observing
Enterprise Architecture decision-making – established in the enterprise architecture and EA policy –
interacting through formal (governance) and informal (collaboration) processes at enterprise, domain,
project, and operational levels.”
The EA function consists of three core activities (Mulholland, et al. 2006):
(1) EA decision making - approving new EA products or changes in existing EA products, and
handling escalations and waivers regarding EA conformance.

12. 8
(2) EA delivery - describes the EA decisions taken, and provides a means for communicating and
enforcing these decisions throughout the organization. It also validates projects and operational
changes to see whether they conform to the EA, and provides support in applying EA products.
(3) EA conformance - responsible for creating and maintaining these products, and provides advice
to guide EA decision making. It is also responsible for implementing organizational changes
through solutions described in the target architectures, complying with the EA policies, and
provides feedback on the applicability of the EA products
2.1.2 Stakeholder Relationship Management
EA stakeholders are individual or grouped representatives of the organization who are affected by EA
products, either by providing input to EA decision making or having to conform to the EA products.
Typical EA stakeholders are senior management, program and project managers, software architects, and
enterprise architects (Vliet, et al. 2008).
(Vliet, et al. 2008) uses the key SA stakeholder roles described by (Smolander, et al. 2002) as a basis to
create a 4 by 4 matrix of EA stakeholders shown in the following figure. The columns represent the four
EA aspect areas, and the rows represent the four organizational levels.
Figure 3 - EA Stakeholder Matrix
(Ian Cole, 2011) defines the following steps for the process of Stakeholder Management in an enterprise:
 Identify stakeholders: includes senior executives, project organization roles, client organization
roles, system developers, alliance partners, suppliers, IT operations, and customers impacted by
the enterprise architecture project, and their key concerns and requirements for EA
transformation.

13. 9
 Classify stakeholder positions: includes analyzing the stakeholders to determine their readiness
to support the effort, their agenda and key priorities.
 Stakeholder management approach: defines the key strategies for harnessing support and
mitigating resistance, and identifies the direction of the enterprise architecture effort to engage
with the stakeholders that have the greatest power or interest to successfully support the effort.
 Tailor engagement deliverables: indentify those responsible for communicating to stakeholders
via what channels, and define the views that need to be produced to support demonstrating the
enterprise architecture’s ability to address a particular stakeholder’s concerns.
Stakeholder management and communications, in conjunction with strong sponsorship and a clear
governance structure, are both areas critical to successful business transformation using an EA framework
(Ian Cole, 2011).
2.1.3 Demand Management
According to Principal Analyst Craig Symons of Forrester Research, demand management is “an IT
governance process that enables IT and the business to optimize the investment in IT through fact-based
decisions.” In other words, it is an automated process for capturing, evaluating, and prioritizing all of the
demands or requests placed on IT—from high-volume routine service requests to deploying changes
across core applications (Mercury 2006).
(P Allen, 2010) states that demand management depends on a good, well-defined relationship with its
partners in the organization if the organization is to progress beyond the “who shouts loudest” mindset.
The organizational model for EA is a convenient place to begin outlining the organizational context for
demand management.
In broad terms, IT business management is driven by business demand and is concerned with ensuring
that IT meets desired business outcomes. Therefore, there should be clear and clean integration between
EA and IT Business Management. In addition, Enterprise Architecture should provide roadmaps of
available assets that enable demand management decisions to be clearly made.
(M. Tam 2012) advocates a process-based approach to demand management that can help IT
organizations more efficiently communicate, prioritize, and fulfill changes to demand. Implementing a
process-based demand management approach is accomplished by following four key steps:
1. Orchestrate processes that give business users the information they need
2. Get a real-time view of all available resources
3. Create a streamlined and predictable approval process
4. Start with “just enough” process and technology

14. 10
Figure 4 - Organizational Model for EA
By implementing the above approach, IT Organizations instantly see how requests are managed through
the entire IT application and service delivery lifecycle. It helps them get started on the right requests in a
faster and more predictable manner. It also helps the organizations determine their real resource costs and
efforts, so they can better respond to demands of the business. Moreover, it improves the overall
productivity and morale of team members.
2.1.4 Project Portfolio Management
(Pennypacker, et al. -2009) defines Project Portfolio Management (PPM) as the centralized management
one or more portfolios, which includes identifying, prioritizing, authorizing, managing, and controlling
projects, programs, and other related work to achieve specific strategic business objectives. PPM ensures
that projects and programs align with the strategies, goals, and objectives of the business. It also
communicates project and program details, including costs and benefits. It provides a holistic, systems
approach to business projects, by managing projects and programs as a whole.
Figure 5 shows the PPM Process in a "swimlane" format detailing specific products and deliverables, as
well as responsibilities (Pennypacker, et al. -2009). In addition to providing built-in governance
processes, PPM also provides project managers the visibility into many projects or program portfolios.
The goal of PPM is to catalog, quantify, and manage project efforts (M.Walker, 2007).

15. 11
Portfolio Management is primarily a project-driven process that focuses on project characteristics. It links
to project resources, focuses on investments in the portfolio and Return on investment (ROI) of programs
and projects. PPM is largely developed around the following elements: providing a centralized view of all
the projects in an organization, enabling a financial and risk analysis of projects, modeling
interdependencies between a family of projects, incorporating constraints on resources shared between
projects, enabling prioritization and selection of projects, ensuring accountability and governance at the
portfolio level, allowing for portfolio optimization and providing support in the form of standardized
processes and software tools (Calderini, et al. 2005).

16. 12
Figure 5 - PPM Process in "swinlane" format (Pennypacker, et al. -2009)

17. 13
2.2 Portfolio Management in Philips Lighting
The department of Information Management Center (IMC) in Philips Lighting runs three services in
order to ensure a smooth flow of business demands throughout IT portfolio for project execution. The IT
Business Partner is the bridging instance between the Business and Market Groups and IT function
ensuring that:
 Business objectives are supported and enabled by IT in projects and programs
 IT works according to the expectations, meaning Operational Excellence
(In other words: IT supporting business growth and enable the business to realize their ambitions)
The performance of IT Business Partners is measured according to the following main KPIs:
 NPS (Net Promoter Score) - User satisfaction and perception of Philips IT and its services &
solutions
 Value created - IT contribution to the business objectives
 Cost - IT cost according to targets
IT Business Partners operate alongside standard processes, such as helpdesks, and are located as close as
possible to the business. The goal is to ensure that every business has a single point of contact towards IT
function who can support and translate business objectives into IT priorities, initiatives and services.
Figure 6 shows the basic processes that are part of the entire Project Management in Philips. As can be
see, the red outline marks the processes that require change as part of the Accelerate Initiative. Currently
there is no process in place for the Identification, Start-up and Initiation phases, and the main goal of the
new operating model is to filter out as many projects as possible before entering the Initiation phase. The
following paragraphs describe the new Portfolio Management process and its key elements as defined by
the Accelerate initiative in September 2011.
Figure 6 - Project Management in Philips

18. 14
Stakeholder Relationship Management:
The primary purpose of this service is to ensure alignment with business stakeholders on their objectives
and concerns. The IT Business Partner has a registered number of Stakeholders with whom he/she
conducts meetings in order to discuss the basic idea behind a project. Based on the outcome of the
meetings, a decision is made whether to proceed with the idea to create a Demand, or to drop it from
further consideration.
Demand Management:
This service involves collecting and validating IT demands for various criteria. Once it has been decided
to proceed with the idea after the Stakeholder Meeting, the IT Business Partner creates a new ‘Demand’
with the basic information about the project – such as the Business Objectives, Problem Statement,
Start/End Dates, Costs, Benefits etc. Once the Demand has been created, the next step is to obtain
Approval by the Tier 1 IT Business Partner.
Project Portfolio Management:
This service basically reflects the priorities, benefits, risks and costs. Once the Demand has been
approved, the IT Business Partner creates a Business Case for that demand, where the finer details about
the project are entered – such as the Financials- IT, Project & Operating Costs; Technical and Business
Risk Assessment and so on. Then, the Business Case is reviewed by the Tier 1 IT Business Partner, and
submitted for approval. The Business Case goes through several stages of Approval hierarchy until it is
finally approved or rejected by the Sector Portfolio Manager.
After the Business Case is finally approved by the Portfolio Manager, the required budget is allocated for
the project and a formal project request is created in the ‘Clarity’ Project Management tool, thereby
making it ready for execution by IT.
Figure 7 provides a “swimlane” overview of the Portfolio Management process within Philips outlining
all the elements within each service described above. A detailed description about each task and the
associated approval roles are described in Chapter 3.

19. 15
Figure 7 - Philips PPM Overview
Key Elements in Portfolio Management:
The following describe the key elements that constitute Portfolio Management in Philips. It is seen in
Chapter 3 how these elements are put to use in the current scenario, which of these are lacking in the
current method, and how it is improved in the proposed solution.
 Transparency (Centralized view of the project portfolio): There is the absolute need for a
centralized view of the organization’s projects, and the first step in this direction requires the
preparation of an inventory of current and proposed projects, preferably through a central area
responsible for collecting, analyzing and distributing project information in a common format.
 Financial Analysis: Although there are several techniques to properly measure the financial
value of projects, Philips uses a valuation methodology based on Return On Investment (ROI)
and Net Present Value (NPV).
 Risk analysis: There are two kinds of Risk Analysis performed on projects in Philips viz. the
Technical Risk Assessment and the Business Risk Assessment. The Technical Risk Assessment is
calculated based on the four main factors: Technology Maturity, Architecture and Design Quality,
Dedication of IT Resources and the Infrastructure changes required. On the other hand, the
Business Risk Assessment is computed based on: the Commitment of Senior Management, the
Commitment of Business Process Owners, the Maturity Level of Business Processes and finally
the Dedication of Business Resources. Finally it is the Risk Adjusted NPV that forms the basis of
the investment decision.

20. 16
 Prioritization and Selection: The selection of projects to compose a portfolio is to ensure that all
areas of Philips’ strategy are properly addressed and that the portfolio is well balanced. It is to
validate that all of the following requirements are met:
Benefits Analysis: This involves the analysis of Business Risk, Business Dependencies, the
Benefits, the Costs (preliminary assessment), ROI, NPV and the Risk-Adjusted NPV.
Program scorecard: This refers to both the Qualitative and Quantitative analysis of the demand.
While Qualitative Analysis includes: Strategic Alignment/Impact, IT Dependencies, Feasible
Start/End Dates, Quantitative Analysis includes: IT Risk, Program Costs, Operational Costs.
Filtering: When the demand is high, it is important to filter out demands that are not aligned with
strategic goals. It also makes sense to filter out demands that have remained ‘idle’ without
obtaining approval for more than one year. Moreover, demands with the worst Program
Scorecard results are also filtered out.
When properly combining the above elements, it gives a very clear picture of which projects
should be cut off and which ones should be funded.
 Need for specialized software: The need for specialized software for Portfolio Management has
always been a controversial issue. While some believe that there is no need at all, others claim
that specialized software is indispensable due to the time consuming process of updating all
information needed for the decision making process. It is due to this that the Philips Accelrate
initiative’s Operating Model decided to use Microsoft Sharepoint 2010 to implement the Portfolio
Management processes.
2.3 How can Enterprise Architecture services be designed and developed?
Although there is plenty of literature available on how Enterprise Architecture can be developed in an
organization, this thesis considers the methodologies used in (P. Harmon, 2003) and (TOGAF ADM).
The primary assumption in both these methodologies is that there exists a group that maintains the
enterprise architecture, called the architecture core team or the Enterprise Architecture Committee, a
group that reports to the executive steering committee and maintains close relationships with the strategy
group and those involved in business process redesign and improvement.
Figure 8 provides an overview of the Enterprise Architecture Alignment Cycle as defined in (P. Harmon,
2003) where the committee functions very much like the planning committee in many large organizations.

21. 17
Figure 8 - EA Alignment Cycle (P. Harmon, 2003)
The TOGAF ADM (Architecture Development Method) describes a method for developing an enterprise
architecture, and forms the core of TOGAF. It integrates various elements of TOGAF as well as other
available architectural assets, to meet the business and IT needs of an organization. Architecture
development is an iterative, ongoing process, and in executing the ADM repeatedly over time, the
architect gradually populates more and more of the organization's Enterprise Continuum. Although the
primary focus of the ADM is on the development of the enterprise-specific architecture, in this wider
context the ADM can also be viewed as the process of populating the enterprise's own Enterprise
Continuum with relevant re-usable building blocks (TOGAF ADM).
The basic structure of the ADM is shown in Figure 9. Throughout the ADM cycle, there needs to be
frequent validation of results against the original expectations, both those for the whole ADM cycle, and
those for the particular phase of the process.

22. 18
Figure 9 - TOGAF ADM model
The ADM is a generic method for architecture development, which is designed to deal with most system
and organizational requirements. However, it will often be necessary to modify or extend the ADM, to
suit specific needs. One of the tasks before applying the ADM is to review its components for
applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This
activity may well produce an "enterprise-specific" ADM (TOGAF ADM).
On the other hand, (P. Harmon, 2003) provides a general overview of the major steps that most
organizations work through for developing an Enterprise Architecture.
1. Agree on the Need
2. Establish an Organizational Structure
3. Select a Framework
4. Select a Tool and Repository
5. Organize the Existing Material
6. Begin Using the Enterprise Architecture
7. Extend and Maintain the Architecture

23. 19
The Research Methodology followed in this thesis uses a combination of both the Enterprise Architecture
development procedures described above.
2.4 How does the development of EA Services impact Portfolio Management?
(M.Walker, 2007) states that Portfolio Management provides many of the multi-faceted aspects that are
required for Enterprise Architectures to be effective, which include Project costs; Supporting business
process and capabilities; Business objectives or missions; Supporting technology and Environments.
(Detecon 2005) suggests an approach based on the TOGAF framework where the technical know-how
from the architecture management arena is brought into portfolio management to streamline the
infrastructure and focus innovation. This involves the deployment of a fully integrated planning process
to deliver full visibility of the dependencies in skills, resources and the architecture.
Portfolio Management provides a repository to store the information needed to support the rest of the
Enterprise Architecture processes. It also provides a backbone to the rest of the EA processes (such as
organizational, strategic, and programs). As EAs build out Portfolio Management repositories, EAs
should attach attributes to applications. These attributes allow EAs to align application architectures to
items such as principles, policies, and standards. This provides insight into the alignment of applications
to the overall vision of the IT organization (M.Walker, 2007).
The EA organizational processes into which Portfolio Management provides information are as follows:
 Technology life cycles (TLC): the process in which a life cycle is attached to an asset.
 Principles and policies: aligning of applications to principles and policies, which is a
fundamental activity for EAs. Also provides the full tractability back to the business.
 Standards alignment: linking to standards; provides a level of governance and proactively to
impact the standards list in a positive way.
 Architecture decisions: This is the bridging of APM information with other information. By
doing this, EAs can make informed decisions.
 Architecture review boards (ARBs): information that is fed into the architecture review
process; provides visibility across multiple domains.
Figure 10 shows the integrated process developed by (Detecon 2005) which is an integrated, easy to
manage and complete approach to transform business needs into IT solutions. This solution tightly
integrates demand, architecture and portfolio management techniques and resources through the planning
process. It helps in being able to quickly focus the IT investment portfolio on business priorities, and
achieve longer term business benefits through transformation of multiple legacy infrastructures to an
adaptive architecture. It also helps in clearly revealing the value of the IT organization for the business.

24. 20
Figure 10 - Detecon's Architecture Process (Detecon 2005)

25. 21
3 Design and Development
3.1 Baseline Architecture: Portfolio Management in Philips until Dec 2011
This section describes the Portfolio Management in Philips Lighting that was in place until the Accelerate
initiative was introduced in late 2011. The following sections explain this ‘baseline architecture’ as per
the TOGAF Enterprise Architecture Framework terminologies. The main sources of data for this analysis
are the documents and presentations in the Project Center Home (Philips Intranet), and interviews with
Lighting ITBPs (Appendix A).
Stakeholder Relationship Management Service:
There are currently over 400 key stakeholders in Philips Lighting, spread over nine Business Units. There
are around forty four IT Business Partners handling these stakeholders with no single standardized
process in place. Moreover, there is absolutely no record of Stakeholder Meetings, and the outcome of
meetings, and no structural communication channel between Stakeholders and IT.
Demand Management Service:
Philips Lighting on an average handles over 450 Demands per year. These demands are registered
through multiple sources and in no standardized manner. The only means of available data is Excel
Sheets, and there are no reporting / monitoring processes in place. Most importantly, there exists no
relationship between the Demand and the Stakeholder information.
IT Portfolio Management Service:
Here, there is a lack of alignment between portfolio and final demand execution. The data available is of
insufficient quality, and there are multiple approval processes in place. There is no well-defined Approval
Process indicating the hierarchy and levels of approval required.
The major problem that arises out of this is that the total costs of all the demands in the year 2011 was
around 180 million Euros, whereas the available budget in Lighting was only 40 million Euros. Hence,
there was the need to have a centralized view on the portfolio, to prioritize the demands and filter out the
unnecessary demands to ensure that the total value of all demands falls within the available budget.
Typically demands submitted by several users were simply ‘sitting’ for several months without being
noticed, and by the time the demands obtained approval, there was not enough budget available to execute
the projects.
3.1.1 Business Architecture:
In the current setup, there exists no concrete, well-defined Business Process in place for the Portfolio
Management. It is broadly defined that there are five main processes viz. Stakeholder Registration,
Stakeholder Meeting, Demand Registration, Business Case (Review & Validation) and Clarity Project
Creation. There is no visibility into the processes and the link between them whatsoever. There are too
many manual approval processes and no clear cut definition of who should approve what. Moreover, all
the processes are highly localized making it impossible to integrate across different locations.

26. 22
The high level of complexity of the entire process leads to dissatisfaction and frustration among the
Stakeholders and the ITBPs, causing a very large throughput time for budget allocation. A broad
overview of the existing processes and roles is depicted in Figure 11 below.
Figure 11 - Baseline Business Architecture: Philips PPM
What happens in reality is first the creation of a so called ‘Project Brief Document’ by the IT Business
Partner. This document contains the basic information about the project and the names of the roles
responsible for approving the project to obtain budget. The document is then circulated to all the
mentioned roles, and individually approval is obtained either by email or by creating new versions of the
same document. Finally after all the people responsible approve the Initiation Document, a formal request
is placed by the Execution Manager to create a project in the Clarity Project Management tool to be ready
for execution.
3.1.2 Data Architecture:
There is no such thing as a Data Architecture in the current scenario. Philips Lighting does not use any
kind of database, and all that is done is file storage. For each project proposal, there exists a ‘Project
Brief’ and ‘Project Initiation’ word documents and several other related documents and presentations.
Regarding Stakeholder Data, there exists a database (Sharepoint 2007) which is seldom used – that too
only for registering Stakeholders and not for recording the Stakeholder Meetings. Moreover, there is no
single central repository where the files are uploaded, and they’re distributed across different servers. The

27. 23
extremely poor data quality due to the lack of a well-defined database makes it impossible to index or
search for specific records.
3.1.3 Technology Architecture:
There are no Project Management Tools being used for this purpose. The only software being used are:
Microsoft Excel, Microsoft Powerpoint, Microsoft Word, Microsoft Outlook (for Approval Emails), and
different Philips Intranet servers (for File Storage). There are no Resource Tracking mechanisms of any
kind, and no means of reporting or monitoring the data based on certain KPIs. In fact, most of the ITBPs
don’t remember where they uploaded which file, and have a hard time even knowing how many demands
exist in their bucket.
Figure 12 - Baseline Technology Architecture: Philips PPM
3.2 Target Architecture : New Portfolio Management method from Jan 2012
The various problems described in the baseline architecture in the previous section clearly advocate the
need for the development of a new Portfolio Management solution. The primary objectives of the
proposed solution are as follows:

28. 24
 Assignment of unique IT Business Partners to every Business Stakeholder to enable stakeholders
with a clear understanding of whom to approach for what kind of projects.
 Creating transparency and speed for all IT demands and their status to the relevant business and
IT Stakeholders.
 Tracking essential information with a Single Point Of Truth (single location with a standardized /
integrated process).
 Drive progress and improve the IT portfolio decision making.
 Assignment of clear roles and governance to agree on common decision criteria - as to who needs
to approve what!
 Establish Monitoring of the quality of data with dynamic reporting features.
The following sections describe the details of the new solution in terms of the TOAGF ADM
methodology – Business Architecture, Data Architecture and Technology Architecture, outlining the
scope, constraints and expectations in each. Figure 13 shows an overall picture of how the proposed
solution would look like.
Figure 13 - Proposed PPM solution
3.2.1 Business Architecture (Target Architecture)
In this section, the Roles and Processes (the Whos and Whats) of the Portfolio Management in the new IT
Operating Model are illustrated. Figure 14 shows the position of the Portfolio Management in the new IT
Operating Model defined by Philips. The characteristic features here are: the project and application
portfolios are controlled by the business; it develops plans and budget in alignment with Business; and the
management of the project and application portfolio is done through roadmaps, budgets and prioritization.
The source of data for the proposal and design of the Target Architecture are the Philips High Level
Document (September 2011), the Portfolio Management Presentation by Philips (January 2012), and
interviews with different ITBPs [Appendix A].

29. 25
Figure 14 - New IT Operating Model, Philips
People and Roles: (Who?) [Appendix B]
IT Business Partner: (Tier 1 and Tier 2)
The ITBP is the key interface between business problem/requirements space and IT/solution space.
He/She is responsible for translating strategic business priorities and objectives into IT solution proposals
per project/program. The ITBP also creates the full documentation stack required for project approval
from idea generation to PID (Project Initiation Document). He/She also defines business and technical
interdependencies for each project(s), assesses technical risks and validates implementation details with
IT delivery and operations.
IT Portfolio Manager:
The Portfolio Manager implements strategic business priorities and objectives for the portfolio. He/She
creates and owns the overall project prioritization list (or rankings) within the portfolio, and drives the
portfolio quarterly roadmap reviews (within the sector) as well as the annual project prioritization. The
Portfolio Manager also ensures completion of artifacts required during the process and rejects projects
which do not meet the criteria. He/She is responsible for the budget allocation within the portfolio, in
alignment with the business and in accordance with the prioritization criteria.
IT Controller:
The IT Controller ensures portfolios are well aligned with financial goals for each quarter or year, and is
responsible for all financials/costs related to projects.

30. 26
Business Owner:
This person is the owner of the overall business program or project requiring IT support. He/She is
responsible for creating the business idea and the business case and to get agreement about it. The
Business Owner is also accountable for the validity and viability of the business program and ensures that
the governance is in place to make effective and efficient usage of the IT tools. He/She ensures end to end
delivery of the business program that depends on the IT project, and escalates in situations where
dependencies are not met.
The Process: (What?)
The basic steps involved in the new Portfolio Management process are as follows:
 Idea Proposal by Business Stakeholder
 Discussion (of the idea) between ITBP and Stakeholder
 Formal Idea Definition by ITBP (Demand Registration)
 Demand Consolidation (Business Case Creation)
 Analysis/Filtering/Prioritization (Business Case Review & Approval)
 Budget Allocation (Clarity Project Request Creation)
The three respective services, and the activities involved in each are described in detail below:
Stakeholder Relationship Management:
The Stakeholder Relationship Management service has two essential components viz. the Stakeholder
Registration and the Stakeholder Meeting Record. The Stakeholder Registration implies assignment of
each and every Stakeholder to a unique IT Business Partner, so that every Stakeholder is aware which
ITBP to approach in case of an idea, and simultaneously the ITBPs are aware who their Stakeholders are.
The next logical step would be the Stakeholder and the ITBP scheduling a meeting to discuss the project
proposal(s). The ITBP then fills out the outcome of the meeting in a form called the ‘Stakeholder
Record’. Now this can be done either during the meeting itself, or after the meeting is complete. The
different details recorded during the Stakeholder-ITBP Meeting are: Business Objectives, Operational
Issues, the most relevant IT issues faced by the Stakeholder, the Minutes of the Meeting and any
improvements or suggestions given by the Stakeholder.
Demand Management:
Submitting an entry into the Demand Portal is the initiation of a business idea which needs IT support.
The new demand process starts with the compilation of valuable demand and high-level data gathering
and analysis. The ITBP (Tier 2) enters the following information which forms the basic Idea definition of
the project proposal:
Project Details:
This is the basic information relating to the Sector, Business Unit, Cluster and Market for the project.

31. 27
Project Description:
This involves further description about the project like the Business Objectives and the Problem
Statement. It also requires the provision of the expected Start Date, Finish Date, estimated Total Costs
and Benefits, and finally the level of Project Complexity.
Responsible Personnel:
Here, all the people/roles responsible for the project are filled in by the ITBP (Tier 2), also known as the
Demand Requestor. The roles to be filled are: the ITBP (Tier 1), the Business Executive Sponsor – this is
the Stakeholder responsible for the Demand, the Business Owner, and finally the Portfolio Manager.
Approval Process:
Once all the necessary information is filled out by the ITBP (Tier 2), this demand is to be ‘Submitted’ to
the respective ITBP (Tier 1) for Approval. The ITBP (Tier 1) reviews the Demand Information and
decided whether to proceed further or not. If the ITBP (Tier 1) rejects the demand, the ITBP (Tier 2)
needs to re-submit it with the corrected data. Once this is approved, it proceeds to the next stage known as
‘Demand Consolidation’. The ITBP (Tier 1) validates that all requirements have been met, and all
projects moving on provide sufficient value to the business and fit within the strategic plan for IT.
Project Portfolio Management:
After the Demand has been approved by the ITBP (Tier 1), a corresponding ‘Business Case’ is
automatically created for that project, with the basic information available from the Demand. It then
undergoes the following steps until it is finally selected for execution and the budget required is allocated.
Demand Consolidation:
The demand consolidation process leads to a grouping of demand within each portfolio. The ITBP (Tier
1) updates the following information in further detail to the Business Case:
 Technical Risk Assessment
 Business Risk Assessment
 Business Dependencies
 Technical Dependencies
 Project Financials – Project Costs, Operational Costs, IT Cost Reduction Benefits, Business Cost
Reduction Benefits, Annual Revenue Benefits and Go Live Year.
As soon as the above information is filled out, the Risk percentages, ROI, NPV and Risk Adjusted NPV
are calculated automatically facilitating the task of Risk Analysis by the ITBP and other personnel who
review the Business Case. Finally, the ITBP fills out the ‘Business Controller’ and ‘Submits’ the Business
Case for Approval.
The Risk Analysis methodology (called the ‘Program Scorecard’) was designed for Philips in October
2011 by Booz & Company, a leading global management consulting firm. Therefore the details about the
how the risks are calculated and the formulas used are beyond the scope of this thesis. The only concern is
about implementing the Risk Analysis functionality in the tool, and to make decisions based on the
numbers.

32. 28
Analysis/Filtering/Prioritization:
The Business Case then undergoes three successive levels of Approval – during which the Risks, Costs
and the Project Financials are reviewed by concerned personnel namely the Business Controller, the IT
Controller and finally the Portfolio Manager. The order of Approval is as follows:
 Business Controller
 IT Controller
 Portfolio Manager
While the Business Controller is responsible for the feasibility of the project in terms of Business Risks
and Operational Costs involved, the IT Controller is accountable for all the IT-related Risks and Costs.
The Portfolio Manager is then responsible for allocating budget within the portfolio, in alignment with the
business and in accordance with the prioritization criteria.
Budget Allocation:
After the Business Case has finally been approved by the Portfolio Manager, this implies that the required
budget has been allocated for the project and is ready for execution. Since Project Execution is carried out
in the ‘Clarity’ Project Management tool, there is the need to raise a request and create a Project in
Clarity. The ITBP (Tier 1) fills out something called the ‘Clarity Project Request’ and submits it to the
Portfolio Manager for Approval. Once the Portfolio Manager approves this request, the Project Support
Office receives an email notification about the details of the project to be created in the Clarity tool, and a
project is created in Clarity accordingly. Now, the project is ready for execution and is completely handed
over to the IT department.
The detailed swimlane model of the Business Architecture is designed using the BPMN 2.0 notation and
is attached along with this report in the PDF file - Philips PPM Process - TO BE Business
Architecture.pdf. Due to the extremely large dimensions of the PDF, it was not possible to include the
figure here. It is recommended to view the file at a zoom level of 250% to ensure efficient readability.
3.2.2 Data Architecture (Target Architecture)
It was decided to adopt Relational Database Management System for organizing the data associated with
the Portfolio Management, which involved the design and data-modeling of five main Tables, and the
relationships between them. The different tables are:
 Stakeholder Registration
 Stakeholder Meeting
 Demand Registration
 Business Case
 Clarity Project Request
Stakeholder Registration:
The main fields on this table are the Stakeholder, IT Business Partner, Sector, Business Unit and a flag
indicating if the Stakeholder is Active or not. The Primary Key here is the Stakeholder ID since each
Stakeholder is unique and is assigned to an existing IT Business Partner.

33. 29
Stakeholder Meeting:
The fields of key importance here are the Stakeholder(s) who took part in the meeting, the ITBP who
organized the meeting, the Executive Whiteboard which talks about the main Objectives, Issues,
Solutions and Actions taken, Stakeholder Feedback, Minutes of the Meeting and finally the Stakeholder
Satisfaction. The ‘Communication Themes’ is noteworthy here because of the ability to customize the
names of the Communication Themes based on the Sector per quarter. (The sub-table Communication
Themes is used for this purpose).
Demand Registration:
The Demand Registration table contains three main classification of fields: Basic Information – the
Demand Title, Description, Sector, Business Unit, Cluster, Market, Earliest Start Date, Latest Finish Date,
Business Objectives and Problem Statement; Financials & Risks – the Total Costs, Total Benefits and
Project Complexity; and the Contact Information section that contains all the roles i.e., ITBP (Tier 1),
Demand Requestor, Business Executive Sponsor (which is a Foreign Key relationship to the Stakeholder),
Portfolio Manager and so on. The Primary key here is the field Demand ID which is of the format
DE000###.
Business Case:
The Business Case table consists of the most number of fields among all other tables, which fall into three
broad categories – the Demand Registration information, Risk Assessment and Project Financials. A
description of the major fields can be seen in Figure 15. This table has a Foreign Key relationship to the
Demand Registration table.
Clarity Project Request:
This table contains the key information necessary in order to create a project in the Clarity Tool Database.
The field-mapping is such that most of the fields on the Clarity database match with those fields here.
This also has a Foreign Key relationship with the Business Case to maintain the link to the Business Case
information as well as the related Demand Registration.
Apart from the five main tables described above, there are few other sub-Tables that are used for
configuration and customization purposes across the five main tables. These would be the following:
 Sector – contains all the Sector Names that use the tool for Portfolio Management: Lighting,
Healthcare etc.
 Business Units – contains the Business Units that exist in corresponding sectors.
 IT Business Partners – list of all ITBP Tier 1 Names per Sector.
 Communication Themes – list of Communication Theme names configured per quarter for
specific Sectors.
Figure 15 below shows an Entity Relationship diagram illustrating the different tables used here and the
relationships between them.

34. 30
Figure 15 - Data Architecture (TO BE)
3.2.3 Technology Architecture (Target Architecture)
Microsoft Sharepoint 2010 was chosen as the tool to implement the entire Portfolio Management
processes at Philips. Prior to finalizing on Sharepoint 2010, a small analysis was carried out as to why to
choose Sharepoint 2010 against two other softwares that were available – the Clarity Project Management
tool and the Microsoft CRM Dynamics. Figure 16 shows an overview of the capabilities of each software,
and the reason why Sharepoint 2010 was obviously chosen.

35. 31
Figure 16 - Sharepoint Selection, Source: Philips High Level Document
It was decided to use only the ‘Out of the Box features’ of Sharepoint’s web-based configuration, and not
to incorporate any custom coding or the use of Sharepoint Designer. This interface provides a general
user interface for manipulating data, page editing ability, and the ability to add functionality to sites.
The web-based interface provides the following abilities:
 Manipulate content in lists & libraries, pages and sites
 Copy, create, delete, or rename lists & libraries, pages, sites and web-parts
 Manage user permissions, and view document/page version histories
 Manage definitions and properties of lists & libraries, pages, sites and web-parts
The step by step procedure followed here in order to implement the complete Portfolio Management
process in Sharepoint is described in details as follows:
Database Configuration: (Sharepoint Lists)
The first task was to create all the tables outlined in Section 3.2.2, and this is done by means of the
Sharepoint ‘Lists’ (Database Objects in Sharepoint). All the five primary Lists and the other secondary
Lists (used for Configuration) were created, and the relationships between them established. The Foreign
Key relationship is defined by the field type ‘LookUp’ in Sharepoint.
Data Entry Forms: (Infopath Template)
The next was to create a user-friendly means of data entry into these lists by means of ‘Forms’. This was
done by means of using the Microsoft Office InfoPath, an application for designing, distributing, filling

36. 32
and submitting electronic forms containing structured data. The most common usage of the Infopath is to
integrate it with the Sharepoint Server for data entry into the Sharepoint Lists and Libraries. (Microsoft
Infopath) lists all the features of Microsoft Infopath in detail. All the data stored in InfoPath forms are
stored in an XML format, which is referred to as the "data source". The main features of Infopath that are
used here are as follows:
 Controls: These are used to present the data from Sharepoint Lists in different forms to the end
users. The most common ways include: Text, Text Area, Radio buttons, Checkboxes, Dropdown
lists and Buttons.
 Rules: This is used to apply specific actions when triggered by an event such as a button click, or
changing values in a particular control. For example, when the ‘Sector’ is selected in a dropdown
list, the related ‘Business Units’ that belong to that selected Sector are queried from the database
and loaded on to the ‘Business Units’ dropdown list. Rules are also used to set field values based
on button clicks.
 Data Validation: This is used to test if an input entered into the fields is valid, by checking if
they are of a correct data type, or matches a specific pattern and so on. Any type of validation rule
can be customized, and since this is done at the Form-Level, it can be done irrespective of the
field type being set to ‘Mandatory’ at the database level.
 Conditional formatting: The appearance or the visibility of the different objects and controls on
a form can be controlled by means of this Conditional Formatting. For example if a Demand
Registration has been submitted for approval, the Submit button must not show up again, or
certain field values should be visible only prior to submitting a record for approval and so on.
 User Roles: The user's experience can be customized by changing views and using conditional
formatting based on the identity of the user. For example, certain fields or buttons should be
visible only to the Portfolio Manager, and not the IT Business Partner.
Approval Processes: (Nintex Workflow)
Once the configuration of the lists and the entry forms was completed, the next logical step was to create
the Approval Processes behind the Demand Registration, Business Case and the Clarity Project Request
lists. This is facilitated by using the Nintex Workflow 2010, a drag-and-drop workflow designer, which
adds connectivity and advanced workflow features to the Microsoft SharePoint 2010 platform.
Nintex Workflow 2010 is an easy to use, browser based drag and drop workflow designer that enabled
workflow actions to support automated provisioning tasks such as: adding/removing users to/from Active
Directory groups; creating, updating, and decommissioning Active Directory accounts. It also supports
add/update/delete operations on the SharePoint Server User Profile Store, including properties, Member
Group, and memberships. Also, Audiences can be created, deleted, modified, and recalculated.
Workflow statistics are available on each workflow providing a holistic view of workflow performance.
This includes details on average run time, total runs, amount of workflows in progress, as well as user
performance, making it a crucial feature to identify bottlenecks in business processes. Workflows can

37. 33
submit documents to SharePoint Server record center sites, allowing for workflows to help manage
content development throughout their entire life cycle, all with an easy user interface and with minimal
complexity exposed to users.
Figure 17 below shows a section of the Approval Processes on the Business Case designed using the
Nintex Workflow.
Figure 17 - Nintex Workflow Designer
User Interface:
Now that all the foundation that is necessary for the Portfolio Management process is ready, the next step
in order to start the usage of the tool is the design of a friendly user interface. It was decided to separate
the Stakeholder data from the Demand/Business Case data by means of separate navigation tabs, since
there would different groups of Users accessing the respective information. So, different ‘Pages’ were
designed with links to the Demand & Business Case information and the Stakeholder Registration &
Meeting information. The complete process overview diagram was included in the Home Page to help the
users understand the complete process. The figure below shows the home page the user lands onto when
he/she accesses the tool.

38. 34
Figure 18 - PPM Tool Home Page
User Groups & Authorization:
Since the goal of the tool is to make it suitable for use by not only Lighting, but all Sectors, each Sector
has different requirements with respect to what they want to see and who should access what. To ensure
this, first different User Groups were created for each Sector. Secondly, the navigation links on the Left
Hand Navigation bar were customized as per the Sector’s requirements, and the link was set accessible
only to the respective User Groups. For example, a user from the Lighting Sector would see only the links
relevant to Lighting, and not Healthcare of Consumer Lifestyle.
In order to do so, several ‘List Views’ were created for the Demand Registration, Business Case and
Clarity Project Request for each Sector. The respective navigations links were assigned to these List
Views and to specific Sector ‘Audiences’. Audiences are groupings of users that can be used to target
content on a SharePoint Server Web site, which allows targeting to the list-item level or to the list level.
3.2.4 Reporting & Monitoring
Apart from deploying and implementing a tool for Portfolio Management that is used for all the above
mentioned processes, it is imperative to have reporting and monitoring mechanisms to maintain an
account of the data being stored, and also to keep tabs on the information being edited through the
different approval processes. This is done by first deciding and defining what the essential KPIs are.
Key Performance Indicators (KPIs) help organizations understand how well they are performing in
relation to their strategic goals and objectives. In the broadest sense, a KPI provides the most important
performance information that enables organizations to understand whether the organization is on track or
not. They are also measures that provide managers with the most important performance information to
enable them to understand the performance level of the organization. The following KPIs are defined in
Philips in order to measure the performance of the Portfolio Management process.

39. 35
Process Transparency:
Transparency here refers to the degree of disclosure provided to the ITBPs and managers with regard to
the activities in the Portfolio Management. The primary need here is for an ITBP to be able to easily
search/track his demand and to be aware of the stage in which his demand lies. It should assist the ITBP
in being well informed about who he should approach for what approval, and how to go about doing so.
To accomplish this, the ‘Demand Status Tracking’ feature was developed using Web-Parts in Sharepoint
2010. Web Parts are sections that can be inserted into pages, and can hold information from the
Sharepoint Lists and Libraries. So, this page consists of three List View Web Parts – Demand
Registration, Business Case and Clarity Project Request, and a ‘Filter’ Web Part that consists of all the
ITBP Names. This enables the IT Business Partner to filter on his name, and have a comprehensive view
of the status of all the Demands, Business Cases and Clarity Project Requests assigned to him.
Figure 19 - Demand Status Tracking
Prioritization:
As it has been discussed in Section 2.2, Philips uses a valuation methodology based on Return On
Investment (ROI) and Net Present Value (NPV). In fact, it is the Risk Adjusted NPV and the ROI that
form the basis of the ‘who shouts loudest’ paradigm i.e., deciding which Projects are to be allocated
budget first. The low risk, high ROI projects are given the first priority, followed by careful analysis for
projects with higher risk. Since the Risk Adjusted NPV is determined by both the Technical Risk and the

40. 36
Business Risk, a means to visualize the four parameters – Business Risk, Technical Risk, ROI and NPV
would be helpful in deciding which projects to include in the pipeline, and which to reject.
In order to achieve this, a ‘Bubble Chart’ was developed using the Google Visualization API and the
Javascript Client Object Model in Sharepoint. This Bubble Chart is a 4-dimensional chart where the X
and Y axes form the Business Risk and Technical Risk respectively. The size of the Bubble if determined
by the ROI, and the color indicated the interval in which the NPV figures. This was developed by
completely coding in Javascript using the CAML Query function in Sharepoint, and the Google
Visualization Bubble Chart API.
Figure 20 - Portfolio Risk Analysis
Figure 20 shows how the managers can view the above mentioned parameters for the projects that are
waiting for budget allocation. It can be assumed that any ‘bubble’ that appears on the top right quadrant is
of very high risk, and needs to be filtered out right away.
Throughput Time:
Throughput time, in this context, is defined as the total time that has elapsed between the minute the idea
was defined by the ITBP (i.e., Demand Registration) and the moment the budget was allocated for that
project after the Portfolio Manager approves it (i.e., Clarity Project Creation). Philips decided on a
threshold of 45 days for a project to acquire budget allocation. The aim here is to not let any project ‘wait’
for more than forty five days to obtain approval from the Portfolio Manager to be included in Clarity.
Once the Portfolio Manager is able to see those projects that have been pending for more than 45 days,
he/she can follow up on it and push the respective ITBP, Business Controller or IT Controller to take
action. To be able to achieve such an overview, again the Javascript Client Object Model in combination
with the Google Visualization API was used to generate a chart as shown in Figure 21.

41. 37
Figure 21 - Throughput time
Budget Allocation – Portfolio Manager:
The aim here is to make the Budget Allocation for the projects as easy and user-friendly as possible for
the Portfolio Manager. Each Portfolio Manager has a fixed annual budget, and it should be ensured that
the total value of all the projects that are allocated budget does not exceed this figure. Therefore, the goal
here is to provide Portfolio Manager with a comprehensive view of the value of: Projects that are already
approved and in execution, Projects that are approved by the IT Controller i.e., pending approval from the
Portfolio Manager, and a feature that enables the Portfolio Manager to see what would be the renewed
budget.
It has been proposed to implement this functionality also using the Google Visualization, but due to the
level of complexity and time required, it was decided to put it on hold until the next Quarter. There is the
possibility to obtain ‘Performance Point Services’ (enables creation of rich, context-driven dashboards
that aggregate data and content to provide a complete view of how the business is performing at all levels.
for Sharepoint 2010) next quarter, which makes it easier to include monitoring and analytic features, such
as dashboards, scorecards, Key Performance Indicators (KPIs), reports, filters, and strategy maps.

42. 38
3.3 Constraints:
There were several constraints and limitations during the development and implementation of the new
Portfolio Management process in Philips. They can be broadly classified into the following categories:
Time Constraints:
The implementation of the new Portfolio Management process was scheduled to start in September 2011,
but due to lack of adequate resource availability and planning, the work could not effectively move at the
predicted pace until January 2012. This delay caused the pressure of working in a much smaller time-
window given the allocated budget. Although there was senior sponsorship and a strong appetite for
positive change, once it was realized that the effort involved in doing things properly will, initially at
least, required a significant amount of time and effort, nervousness, uncertainty and push-back was
unavoidable. So, the development methodology was more ‘Agile’ with minimal planning involving
several iterations that lasted for an average of two weeks.
Low Data Quality (Master Data):
The reasons mentioned above led to the development of a highly faulty database model during October
2011, and around three hundred Demands and Business Cases were exported from spreadsheets into this
Database. The tables created had no organized structure – no Primary Key / Foreign Key relationships,
too many ‘free form text fields’ being used for purposes like storing the names of people, no meaningful
naming convention and very high redundancy. Therefore, it was a humungous task requiring both skill
and time to design and migrate the old data to the new model shown in Figure 15.
Technology Constraints:
One of the biggest constraints here was the lack of a dedicated ‘Development’ environment for
Sharepoint 2010. Due to the lack of time and budget, it was decided to directly work on the Production
Server, without following the standard procedure of developing in a Development Environment, testing
and then deploying to Production. This meant that the ‘Sharepoint Designer’ could not be accessed at all.
The Sharepoint Designer is a specialized HTML editor and web design freeware for creating or
modifying Microsoft SharePoint sites and web pages. Not being able to use the Sharepoint Designer has a
number of limitations with respect to customization of lists and pages.
Another impeding factor was the inability to install the ‘Performance Point Services’. The Performance
Point Services are used for creation of rich, context-driven dashboards that aggregate data and content to
provide a complete view of how the business is performing at all levels. With this feature, it is far easier
to include monitoring and analytic features, such as dashboards, scorecards, Key Performance Indicators
(KPIs), reports, filters, and strategy maps.
An alternative for dynamic reporting was to buy ‘Custom made web-parts’ that are available online. But it
was decided by Philips that neither Performance Point Services nor buying web-parts will be possible for
this quarter since the procedure for raising a request to enable it and have it installed would’ve delayed
the project much longer.

43. 39
4 Communication & Validation
4.1 Communication
The design, development and deployment of a new process is one thing, but making sure it is well
communicated to the necessary users in order to start the rollout and usage of the tool is another major
task. On completion of the deployment of the new Portfolio Management process in Sharepoint 2010, the
following initiatives were taken to ensure Sector wide communication of the existence of the tool.
4.1.1 Training Session: Live Meeting:
Two training sessions were organized on March 26th
and 27th
2012, to make all the Lighting ITBPs aware
of the new Portfolio Management process, and to familiarize them with the Sharepoint tool. This was two
Microsoft Live Meetings conducted for 3 hours on both the days. There were around a hundred attendees
from The Netherlands, Germany, The United States, India and China.
The first part of the training consisted of the explanation of the entire process overview – the Stakeholder
Management, Demand Registration, Business Case, Risk Analysis, Approval Processes etc. The second
part of the training was a complete demonstration of the process using the Sharepoint tool – right from the
Stakeholder Registration until the Clarity Project Request is approved.
At the end of a training session, a short survey was sent out to the attendees asking them to answer about
10 questions their understanding of the process and the quality of the survey. Despite a hundred attendees,
the number of responses for the survey was only thirteen. Since it was realized from the Survey responses
that most of the Users were still not comfortable with the understanding, and expected more audience
participation, the following training session was carried out.
4.1.2 Training Session: Hands-on Demo:
On May 2, 2012 another training session was conducted for all the IT Business Partners in Eindhoven.
This was organized in a different manner compared to the previous presentation. Prior to this session, five
dummy sectors were created in the Sharepoint Site to be used for testing purposes. There were around 20
IT Business Partners split into groups of four each, and each group member was assigned a specific role
viz. IT Business Partner (Tier 1), Business Controller, IT Controller and Portfolio Manager.
Each group was asked to perform all the activities in the Portfolio Management process like registering a
stakeholder, recording a Stakeholder Meeting, creating and approving Demand Registration, Business
Case and so on. This was a highly interactive and dynamic session where people actively participated and
gained hands-on experience in answers to questions like – how to register a demand?, how do I approve?,
how do I see who the demand is pending on? etc.
4.1.3 Document Repository:
Finally, a repository was created to store all the related documents so that the users can refer it any time in
case of any doubts or queries. A separate Sharepoint Site was created and organized into two sections
namely the Stakeholder Tool Documents and Demand Tool Documents. Each section consisted of

44. 40
Powerpoint presentations about the overall process, and a simple/easy-to-use User Guide about how to
use the respective tools. On completion of the repository, a link was added to the main site’s left-hand
navigation enabling the users to access it easily.
4.2 Validation
In this section, a comparison study is carried out about the method followed by the projects prior to
introducing the new Portfolio Management methodology, and is contrasted with how project selection is
improved and different in the new methodology. At first, a project that was implemented more than a year
ago is discussed – a brief introduction of the project is provided, followed by the process description, and
the analysis outlining the reasons that led to delays or failures.
In the subsequent section, two projects that were allocated budgets one month ago, based on the new
improved method are discussed. Here, following the brief description of the projects, the criteria on which
the entire budget allocation process was made more transparent and easier are described.
4.2.1 Old Method
Project – Q2C Business Center Process Improvements, March 2010
Introduction:
The Quote to Cash (Q2C) Strategic Program aims to improve and simplify the Q2C process through
fundamental changes to Philips’ Supply Chain. The projects that are part of the Q2C program are
targeting critical processes to improve the efficiency, effectiveness and transparency of the Q2C cycle.
The goal of this project is to improve Philips’s competitiveness, reduce the internal complexity for
employees, and make it easier for customers to do business with Philips.
This project was to provide improved processes for functional areas residing within the Business Center
in order to reduce overall complexity improve efficiency and establish harmonized Q2C processes on a
global scale for commercial operations.
Project Initiation Process:
Project Brief Document:
The very first version of the Project Brief document was created on March 6, 2010 by the Business
Demand Analyst in the GSS International Business Unit. This document was refined and revised several
times and the final version was released in June 2010 after a discussion with the IT-Architecture Platform
Manager and the Senior Supplier.
Project Brief Approval Process:
The finalized version of the Project Brief was circulated for approval among several roles such as:
Business Process Owner Supply Excellence, Sector IT Business Program Manager, Business Line
Portfolio Execution Manager, Value Space Certified Architect and Senior User. After all the mentioned

45. 41
roles here approved this document, a formal request was made to create a Sharepoint Site by the Project
Manager in the beginning of July 2010.
Request for Sharepoint Site:
A formal request was made to create a dedicated Sharepoint Site for this project to the PSO Central
Mailbox. Here, the relevant information about the project and the roles involved were provided. It was
clearly defined who should have Full-Control permissions, who should have just Edit-Level permission
and finally those who should just be able to ‘View’ records. Once the Sharepoint Site for the project was
ready, all the Project Brief document versions were uploaded to it, and then a Project Initiation Document
was created by the respective Project Manager in July 2010.
Project Initiation Document:
The Project Initiation Document consisted of the information about the Business Risk Assessment, the IT
Architecture, Project Organization Structure, tentative Project Plan – the costs involved and the proposed
timeline. The Business Risk Assessment was done by a method called the ‘Business Impact Risk
Analysis’ impact spreadsheet. This document was then circulated for Approval among: the Senior
Supplier, Senior User, Project Manager, Change Manager, Value Space Supply Excellence CIO, Value
Program Manager and the Sector IT Controller.
All the document versions, BIA Risk Analysis Spreadsheet and the entire list of approval emails were
stored in the requested Sharepoint location in a meaningful folder structure.
Clarity Project Creation:
After all the roles to which the Project Initiation Document was circulated to approve the document, the
Project Manager sent a formal request to the Project Support Office (PSO) to create the required project
in the Clarity tool. Therefore, the project was finally ready for execution on August 8, 2010.
Analysis:
The following can be inferred based on the process the above project underwent in order to obtain
approval for the Project Initiation phase.
(i) Time frame exceeded: The project was schedule to start in June 2010 but due to several unforeseen
reasons could not be started before the second week of August. No exact reason can be attributed to this
delay, but one of the possibilities is Extended Leaves taken by some of the Approvers during the Easter
Break. This caused the backlog handling processes to also take more time to complete, and no clear
information was available about the delegation of the backlog processes. Moreover due to a lack of well-
defined structure, the repeated refining and versioning of the Project Brief document is another serious
time consuming factor. The total time taken right from the introduction of the initial Project Brief until the
creation of the Project in Clarity was about 5 months.
(ii) No transparency or monitoring mechanism:
In the event of any question or doubt raised by any of the persons involved in the project, there was no
availability of a clear-cut process to refer to. Most of the persons were not clear as to who should approve
what, and the Project Manager had no means to find out the status of the project in case of any delay. He
also had no idea who the project should be escalated to in the event of any dispute or delay in approval.

46. 42
The primary reason for this was the major reorganization that took place in Philips in the last two years.
Moreover, asking every approver to read through the entire document is a painful process, and is a major
cause of delay and erroneous assumptions.
(iii) Budget Exceeded by 42%:
The planned budget for this project was initially 144.932 EUR, but at the end of the project execution the
actuals spend was 205.000 EUR. This is a whopping 42% increase in expenditure. One of the reasons
attributed to this is the lack of a well-defined Risk Analysis methodology. A more accurate calculation of
the Business and Technical Risk dependencies might have led to a more specific determination of
budgets. Moreover, this project adopted a standard Water Fall approach which does not work simply
because business requirements could not be captured in one go, but is an ongoing process. By confirming
the scope upfront, it becomes a problem when the scope needs to be changed, and especially the budget
needs to be increased.
Therefore, the entire analysis can be summarized as shown in Figure 22. In the following section, it is
seen how several of these issues are prevented by using the new Portfolio Management model designed
according to Section 3.2.
Figure 22 - Project Initiation in 2010

47. 43
4.2.2 New Method
In this section, two different projects that were allocated budget and initiated by using the new Portfolio
Management process are discussed. At first, a short introduction about each project is provided, followed
by the different aspects which are improved in the new method compared to the method described in the
previous section, and finally, the reasons and the basis for budget allocation are explained. The two
projects described here are quite contrasting in nature with respect to the costs involved, the timeline and
the nature of the Business Stakeholder.
Project 1: Lighting - SAP Lighting 2013
Introduction:
The ‘SAP Lighting 2013’ is a program to converge to one application stack for the Lighting sector by the
end of 2013, early 2014. The goal of the project is Harmonization and Simplification of processes and IT
landscape by adopting industry best practices for processes and IT configuration. The ambition is to
reduce cost and operational complexity (business and IT) by converging to one IT system, and enable the
global End-to-End business transformation.
The following are some of the essential information about the project.
 Expected Start Date: April, 2012
 Latest Finish Date: June, 2014
 Total Costs: 57.000.000,00 EUR
 Total Benefits: 180.000.000,00 EUR
 ROI: 315,79 %
 Business Risk: 0%
 Technical Risk: 33%
Process Timeline:
Total throughput time: 12 days
Activity Date
Demand Registration Created March 30, 2012
Submitted for ITBP (T1) Approval April 1, 2012
ITBP (T1) Approved April 3, 2012
Business Case Created April 3, 2012
Business Case Submitted April 4, 2012
Business Controller Approved April 4, 2012
IT Controller Approved April 6, 2012
Portfolio Manager Approved April 8, 2012
Clarity Project Request Submitted April 10, 2012
Project Created in Clarity April 11, 2012

48. 44
Risk Analysis:
The IT Business Partner just had to select the relevant dropdown values in the Business Risk Assessment
and the Technical Risk Assessment sections on the Business Case Form, and based on the values selected
the percentage of the risks are calculated automatically as shown in Figure 23. The Business Controller
and IT Controller just need to review these sections to see if the Risks are permissible and within the
threshold. (as opposed to reading through a huge document in the previous method)
Figure 23 – Business Case Risk Analysis
Budget Allocation:
The minute the Business Case is sent to the Portfolio Manager for Approval, he/she receives an email
with a brief description of the project and a direct link to the specific Business Case. All that is required
by the Portfolio Manager is to simply click on the link, and review the ‘Project Financials’ table on the
Business Case. The fields that need to be reviewed by the Portfolio Manager are the Total Costs, NPV
and ROI and check if the numbers would meet the budget requirements. (Shown in Figure 24)
Figure 24 - Project Financials
Criteria for Budget Allocation:
This project is of extremely high business value with a Return On Investment of over three hundred
percentage. It is classified as an ‘End2End’ initiative according to the new Philips Accelerate model.
Moreover, it is a long term project that is expected to last two years, and is funded by the Lighting CEO
office, a Business Stakeholder with utmost priority. This project is a huge initiative taken by the office of

49. 45
the CEO as part of the Accelerate initiative. Therefore, the criteria for budget allocation here simply goes
by the “Who shouts loudest” mindset based on the business value and the Stakeholder priority.
Project 2: Lighting: DC Greece (DHL) OPI Interface
Introduction:
The objective of this project is the setup of the necessary interfaces between Philips Lighting Greece &
DHL in order to replace the manual way of working established after the activation of the contingency
plan. Automated interfaces would allow to save additional handling costs (35K EUR per annum),
corrections due to human mistakes made (29K EUR per annum), surcharge by DHL for continuous
workaround (16K EUR per annum), next to less missed sales and very likely fine by government (60K
EUR per annum). The impact would be that if they were to continue with the current manual way of
working, the amount of money burnt would be 80-140K EUR versus a boxed budget of 60K EUR
available.
The following are some of the essential information about the project.
 Expected Start Date: May 1, 2012
 Latest Finish Date: June 30, 2012
 Total Costs: 30.000,00 EUR
 Total Benefits: 100.000,00 EUR
 ROI: 233,33 %
 Business Risk: 12%
 Technical Risk: 12%
Process Timeline:
Total throughput time: 16 days
Activity Date
Demand Registration Created May 1, 2012
Submitted for ITBP (T1) Approval May 1, 2012
ITBP (T1) Approved May 3, 2012
Business Case Created May 3, 2012
Business Case Submitted May 5, 2012
Business Controller Approved May 9, 2012
IT Controller Approved May 10, 2012
Portfolio Manager Approved May 14, 2012
Clarity Project Request Submitted May 16, 2012
Project Created in Clarity May 16, 2012
Criteria for Budget Allocation:
This project on the other hand differs in various aspects as compared to the previous one. The total cost of
the project is much lower, and so are the Business Risk and Technical Risk assessment. It is an ‘IT
Simplification’ initiative according to the Accelerate operating model. Moreover the expected duration of

50. 46
the project execution is only sixty days. Budget allocation for such projects can be considered to be done
on a “first come first serve” basis. So, the faster the Business Case is submitted for approval, the higher
the chances of obtaining budget.
4.2.3 Comparison:
The table below shows a broad comparison of the aspects in which the project that was initiated using the
process prior to introduction of the new model differs from the two projects that underwent budget
allocation via the newly introduced model.
Project
Old Method
(4.2.1)
Project 1
New Method
(4.2.2)
Project 2
New Method
(4.2.2)
Overall Throughput Time > 150 days 12 days 16 days
Risk Assessment Methodology
 Business Risk
 Technical Risk
N/A
N/A
0%
33%
12%
12%
Process Transparency
 Can I track the status of my demand?
 Do I know who the Approvers are?
Prioritization
 Do I have a centralized view of the Portfolio?
(based on Total Costs, ROI, Risk Adjusted NPV)
Repository Available
 Can I refer the entire process somewhere?
(in case of questions or queries)
Monitoring Mechanisms
 Bubble Chart - Portfolio Risk Analysis
 Column Chart - Throughput Time Progress

51. 47
5 Conclusion & Future Work
In this final chapter of the Thesis, it is retraced and assessed how far the thesis work has progressed since
the definition of the research question in section 1.3. Chapter 2 was completely devoted to the description
of the concept of Enterprise Architecture and Portfolio Management, and insight into the methodology
used to develop Enterprise Architecture Services that can be used for Project Portfolio Management.
While the first part of Chapter 3 covered the analysis of how IT Projects were allocated budgets prior to
introduction of the new model, the latter part provides a detailed description of the design and
development of the target architecture. Finally, it is seen how Chapter 4 answers the general research
question defined in section 1.3.
5.1 Answers to Research Question
“How does the development of a specific set of Enterprise Architecture Services influence / impact the
selection of IT Projects (Project Portfolio Management) in Philips Lighting?”
Here, it is seen how the above research question defined in 1.3 is answered with respect to the initial
Figure 1. Looking at the figure, the ‘Enterprise Architecture Services’ block was addressed in detail in the
first part of chapter two. The three independent services and the inter-relationships between them were
described in detail with relevant references to research papers. Following that, the ‘Project Portfolio
Management’ block on the right was looked into in the second part of Chapter 2, where the situation in
Philips and the manner in which the organization ran the selection of IT Projects was explained.
With regard to the third ‘Method of Using the Services’ block, while the theoretical underpinning of
Enterprise Architecture Development methodology was talked about in section 2.3, the actual analysis,
design and implementation of the services in Philips was covered in Chapter 3. While the ‘current
problem’ is covered on a more general/organization wide aspect in the third chapter, the fourth chapter
explains the problems in further detail specific to the initiation of a project. (Section 4.2.1)
Finally, the latter part of the fourth chapter covers the selection of IT Projects using the new method, and
validates how most of the problems identified in the old process are overcome in the newly deployed
process based on the aspects – Project Prioritization, Budget Allocation, Process Transparency and
Throughput Time.
Project Prioritization is simply done by ranking the projects based on the Total Costs, the ROI, the risk
adjusted NPV and the level of satisfaction and priority of the business stakeholder. The Budget
Allocation is easily performed by the Portfolio Manager based on the ‘who shouts loudest’ paradigm for
projects with extremely high business values and low risks, and ‘first come first serve’ basis for small
initiatives. At any stage, all the IT Business Partners and Managers are aware of the status of their
demand, and are well informed about whom to obtain approval from ensuring organization wide Process
Transparency. Finally, the elimination of several documents and the need for reading them in detail and
repeated versioning reduces the overall Throughput Time drastically.
Figure 25 shown below provides a holistic view of Figure 1 with respect to this Thesis.

52. 48
Figure 25 - Conclusion
5.2 Assumptions and Limitations
On conclusion of this research project, an important factor to consider here is to review the research
design and review its limitations, and the assumptions based on which it was designed. One of the main
limitations was the lack of formal specification of the previously implemented processes, and it was
extremely cumbersome to identify the relevant activities and the associated actors in charge of the
activities.
The entire design and implementation was a highly iterative process with constant changes in finalizing
the approval processes and modifying the data architecture. Therefore the set of business requirements
could never be captured in one go, and any changes to be done always took more time than expected.
Moreover, the technological constraints described in section 3.3 formed the biggest hurdle, and the
organization did not have enough budget to invest in a more up to date, state of the art technology.
The validation of this design is based on just the two specific projects discussed here, and the same cannot
be assumed for all kinds of projects that require budget allocation. For example, there is no information
about the actions to be taken if the approval is pending for several weeks on a specific role, who it should
be delegated to and so on. Also, it is to be noted that none of the details about the project execution are
taken into account here, and is purely to do with the project initiation phase only.
Also, the Risk Analysis methodology used in the Business Case, the calculation of ROI, NPV and other
costs, the details about the working of the Clarity Project Management tool and the criteria to determine
the priority of the business stakeholder are considered outside the scope of this Thesis.

53. 49
5.3 Suggestions for Future Research
5.3.1 Deployment to Philips Global
The newly developed Portfolio Management method covered in this Thesis was first deployed and rolled
out in the Philips Lighting organization during the end of March 2012. Since the goal of the Accelerate
initiative’s Operating Model is to have a single standardized process for Portfolio Management across all
sectors, Philips Healthcare also took keen interest and started using the new tool. Although most of the
requirements are same across sectors, there are minor differences in the amount of information captured
and the Approval Roles that are specific to the sector. Towards the end of April, the sector CFCT
(Corporate Functions/Corporate Technologies) also expressed their interest in using this for handling their
Portfolio Management. Currently, CFCT is in the process of communicating this to their users and is
expected to start using it by June 2012.
Recently, during the last week of May, the Philips Global’s ‘Group Management & Services’ sector also
came to know about the tool being used by Lighting, Healthcare and CFCT, and have shown interest in
deploying it for their ‘Platforms & Architecture’ organizational unit too. A demonstration of the process
was done to their sector during the last week of May, after which they have finalized the project to move
their entire Portfolio Management process towards our developed solution in Sharepoint.
5.3.2 Web service Integration with Clarity
Currently, although the project initiation and budget allocation is carried out in a systematic manner, the
final step of making the project ready for execution by creating the project in the Clarity Project
Management tool is still a manual process. The Project Support Office (PSO) person receives an email
with details about the Clarity Project Request created in the Sharepoint site. On receipt of this email,
he/she has to manually create a project in the Clarity tool by mapping the field values from the Sharepoint
List.
Although this process works fine now, it is not completely foolproof and there can arise issues like
erroneous entry, missing some information and so on. Moreover, in case the concerned PSO person is on
leave, or happens to miss the email, the project creation process can be indefinitely delayed. Therefore, an
initiative was taken by the Lighting IT Organization to make this process automated i.e., the minute a
Clarity Project Request is approved in the Sharepoint site, it automatically creates a project in the Clarity
Project Management tool, and updated the specific project ID in Sharepoint.
The project was initiated and finalized during the first week of May 2012, and is still in progress. The
goal is to use web services to achieve this integration. The Clarity tool provides a WSDL interface to
receive SOAP requests from Sharepoint. Once a Clarity Project Request is approved in Sharepoint, a
SOAP message request is constructed as per the Clarity WSDL schema, and a web-service callout is
made to the Clarity endpoint. On receipt of this request, Clarity creates a project in the tool and returns
the created project’s ID as the response. The minute Sharepoint receives the response, it updates the
record with the returned project ID. The operations are clearly outlines in Figure 26.

54. 50
Figure 26 - Clarity Integration