The European Parliament (EP), a key player in European Union legislative procedures, operates a well-run IT Directorate that has grown significantly over the years, in terms of personnel, scope, organisational maturity, and visibility within Parliament.
One of the results of the growth of the IT Directorate is that the Directorate has to deal with an ever-increasing number of requests from its internal customers, especially in the field of business application development, whereas the budget available did not increase accordingly.
The European Parliament, using the Val IT™ framework published by ISACA, successfully implemented a multi-annual IT plan, prioritising IT investments and business-as-usual work requests following solid, transparent, objective and widely accepted criteria, which are in line both with the IT strategy and with Parliament’s general long-term goals.
The IT Portfolio Process: Val IT Implementation
The IT Directorate is the central IT service provider for the whole of Parliament; as such, all of Parliament’s services are potential customers of the IT Directorate. The Directorate has been operating with tight controls on project execution and financial management for years; however, the growing number of client requests, combined with a tight budget, made it necessary to extend controls to include decisions on investment choices, and to ensure EP gets all expected benefits from the investments. The problem is most sharply felt in the area of application development, where the requests for activities typically outnumber the work capacity by a factor of three.
From the outset, it has been clear that the political, public-sector environment in which the EP operates, is different from, and in certain regards more complex than, that of a private sector company:
- Parliament’s environment contains a number of actors (political authority) and forces (political acceptance) that are not typically present elsewhere.
- Since Parliament is spending taxpayers’ money, EP has to live up to the highest possible standards of transparency and accountability.
- The public sector does not have cut-and-dried measures on what constitutes a benefit (such as return on investment). Benefits are often complex in nature, intangible, hard to quantify and accruing to a diverse set of stakeholders.
Taking all this into account, a process was designed to assess the relative priority of all requests for work and to establish a portfolio of planned work requests. The process is supported by a home-grown, web-based tool.
The key features of this process are:
Management of sub-portfolios of related requests per business domain
To be able to offer a better service to the internal customers, it has been decided to break down the portfolio into four different business domains, following the natural division of activities of the Parliament. These domains are:
- EP members and political groups
This allows EP to get a clearer visibility of relationships between related requests, makes it easier to identify synergies and allows more weight to be given to certain business domains during request evaluation, in line with political priorities.
Better categorisation of requests
Parliament’s portfolio of IT activities is made up of different types and categories of requests and activities, which have different levels of complexity and for which the degree of freedom for allocating funds varies greatly. Thus, the requests have been further broken down along the following axes:
- Each request has been assigned a level indicating how discretionary the spending on the request is, ranging from highest (Parliament is under a legal obligation to act on the request) to lowest (discretionary spending on new activities).
- Requests have been broken down into two investment types (new investment requests as opposed to business-as-usual requests).
Multi-dimensional assessment of requests
The approach provides for a multi-dimensional assessment of requests, using a number of transparent and measurable evaluation criteria: criticality, expected business benefits, foreseen business risk, compatibility with the IT systems strategy, request maturity, costs, IT risk and political impact. Each of these criteria is assessed through a number of questions, the answers to which are backed up with satisfactory evidence by both request owners and technical assessors.
Improved prioritisation mechanism
To compare and prioritise activity requests submitted for inclusion into the IT plan, EP applies a prioritisation mechanism based both on the nature of the requested activity (business domain and categorisation) and on a scoring of all valid requests on the basis of the multi-dimensional assessment described previously. A prioritised list of requests can thus be obtained, providing a sound and rational basis for the allocation of funding and of human resources. It has to be outlined that, although the prioritisation is done by an algorithm, the results of this algorithm are not applied blindly, but pass through the filter of a ‘sanity check’ review by business users and the IT Directorate.
Several measures have been implemented to ensure appropriate accountability for planned requests:
- Request evaluation is done in close collaboration between business owners and IT Directorate staff. Some evaluation criteria (business benefits, business risk and criticality) belong exclusively to the business users.
- Each request is owned by a specific organisational unit of EP and has a named main sponsor. This main sponsor has to be at a certain minimum hierarchical level within the Parliament’s administration.
- A request cannot be approved unless it has a named contact person at the business side. The availability of this contact person is assessed during request evaluation.
- When evaluating a request, the request’s completeness is taken into account. A request can be approved only if judged to be sufficiently complete. Request completeness is proven through certain project artefacts (business case, needs study, etc.). Although these artefacts are produced in close collaboration between the business side and the IT Directorate, the business users need to prove that their request is sufficiently complete to be taken into account.
Although the portfolio planning and management process had originally been set up for business application development projects only, the process has now been extended to cover all services offered by the IT Directorate. That way, the plan provides a one-stop shop for everyone looking for detailed information on all activities scheduled by the Directorate.
The portfolio currently covers a rolling horizon of one year. To give a better visibility to customers, EP is in the process of extending the horizon to three years. This will allow more effective handling of multi-year endeavours within the plan, and will give business users submitting requests for work that cannot be accepted in the immediate future an idea of when their requests may be addressed.
To integrate the planning process and portfolio management with project planning and execution, and to be able to closely monitor, evaluate and improve value delivery by projects, the home-grown web application is currently being replaced by a commercially available project and portfolio management tool.
Using Val IT as a guiding framework for designing the planning and portfolio management process, the European Parliament has been able to identify the right projects to implement, and has a way of following up on the benefits generated by these projects. It is important to point out that the process’s transparency allows EP to create a large consensus between business users and technical people that EP is doing the right thing, at the right time, within the constraints of the means available.
Having one global portfolio that covers all activities of the IT Directorate provides upper management with a first-class tool to oversee and steer the full scope of activities of the Directorate. The extension of the rolling horizon provides EP with a visibility over the full life cycle of most of its activities.
Case Study Disclaimer
This case study is intended for informational purposes only. The advice, opinion, statements, materials and other information expressed and contained in this case study are solely those of the authors and do not necessarily reflect the views, policies or opinions of ISACA or the IT Governance Institute (ITGI). ISACA/ITGI is not responsible for the accuracy, currency, completeness, reliability or usefulness of any advice, opinions, statements or content contained in the case study and makes no claim that use of the case study will assure a successful outcome.