To achieve this, the obvious things to consider would be running costs, business value and operational indicators while engaging with owners to get real life information. Therefore, in this light, ITPM is a great tool that support daily management and assessment of the landscape BUT are these daily management indicators enough for you to enable and drive changes to achieve real value in transformation?
Imagine yourself as the property agent responsible for the management of an office block: to start with a spreadsheet of all the tenants and their rent is needed. Then there is the water, electricity and telephone costs, the number of people, the level of internet service needed - so you can see that we’re starting to build up a relatively comprehensive spreadsheet now.
Let’s now factor in building maintenance that needs to be scheduled in, fire drills, insurances, tenants changing and even handling complaints and requests for changes… now this requires several spreadsheets that cross reference each other…Can’t require much more that, can it?
The above would perfectly support all the regular analysis you need to do to keep the business profitable and identify minor change required to improve its value: beyond daily management, you may hear of a gas supplier offering similar services for a better price or decide to rent a few offices out for meeting booking at a higher rate. But what in your spreadsheet is going to warn you that the new boiler installed 2 years ago requires specific knowledge this new provider doesn't have, that the structure of the meeting rooms is not fit for purpose? How are you going to come to the conclusion that the best option is to transform those 2 offices into one larger office rented out by a bigger company and potentially bringing new clients?
Much like our building analogy, the Applications in our estate require managing and controlling in a more rigorous manner than just a simple spreadsheet – for this reason we chose to refer to ITPM rather than just APM.
ITPM is the ideal tool to manage your IT assets. Based on collaboration, it gathers and presents relevant information through inventory and assessment in order to be consumed efficiently, to raise attention to main areas of interest. However, by looking at your IT Portfolio from an Architecture and Risk Analysis viewpoint, it will provide a more complete picture to analyse the impact of change and help drive transformation. Let’s take a look at the reason why…
Usually the ITPM adventure starts with key questions and objectives: reduction of the number of applications to achieve targets, improvement of visibility on vendor support to avoid unpleasant surprises on contract renewal, identification of application redundancies to optimise functional support, externalisation of application support...These goals are drivers for inventory and assessment to collect data and identify the applications to analyse more closely. To maximise the value of your analysis it is important to identify these questions, understanding they will evolve through iterations.
The analysis of your IT Portfolio is based on a set of criteria you collect through inventory and assessments: popular choices are total costs of ownership and their breakdown, business value, application criticality, intensity of usage and application lifecycles. Candidates for transformation are identified through reports like the Gartner TIME report 1 first identifying the applications to eliminate, invest in or tolerate based on chosen criteria of analysis.
However, if scenarios analysis is limited to those criteria, we will never have visibility of the high-tech boiler and its special service knowledge. What about leveraging information regarding the number of interfaces to other critical systems? The current projects with these applications in their scope? How much of capabilities the applications cover functionally? What is the technical debt? How much high-impact risk applications are subject to? Completing your analysis with architectural and risk-based criteria highlight impacts of change which are valuable during the road mapping exercise. It supports more informed decisions and engage both Portfolio Managers and Architects through projects in the IT Assets landscape evolution.
Therefore, we can see that architectural projects and ITPM analysis share a lot in common. Saying that however, it is not uncommon to find the respective processes acting separately. Transformation will have more chance of being effective when both Architects and Portfolio Managers work collaboratively and feed information to each other as they are both contexts that could potentially impact the life and evolution of an application. It is only when this happens, that you will have a complete view over your environment and assets to ensure that you can support those ever-changing business requirements.
Reference Source: 1 Application Portfolio Triage: TIME for APM
... View more
Given the choice, this would be a fast engine, leather seats and the highest comfort all the way: even when we start listing the potential drawbacks, it still seems a good choice. Seeing all the options can lead us to forget the original requirement, running the risk of attempting to create the most powerful system possible, which is ultimately abandoned because it failed to achieve the desired goal.
Whether you are looking for business transformation or GRC tools, we quite naturally select systems based upon our key objectives: getting from A to B on the road and comfortably with the potential to take the flock I have just bought on holiday! We start with how tools achieve these objectives during demos, but then also how much more they can do for us: a functional van, a livestock trailer, a 4x4…
Standard features sometimes seem too restrictive or not exactly to our taste: seating is not very comfortable; I may need to add some space if I owe cows one day too; grey is really a sad color: what about yellow? We request configurations and customisations before we have even explored what is possible with the standard features.
We think about what we might need in the medium or long term: about this specific case occurring in a tiny percentage of cases that we might need to support; we may not find a field they like and so need to grow backup grass at the back of the van; about reports we might have to support or required to make instant decisions based upon our own clever calculations; what about a flashing light telling me when to break; about cool features we could provide to end users and enable them to do more or do more for them.
From the very functional van we originally looked at, we now see emerging a limo-like vehicle with all options activated and here we are, discussing more about how to configure advanced options; we have dreams of integrating a voice-responsive expresso machine, adding another set of doors on the roof and setting up THE red button pushing our vessel in the sky.
Don’t get me wrong, I would love to be flying in my car sipping freshly made espressos, although I am not sure livestock I might own would appreciate the ride! Mais retournons à nos moutons…
Wait…what did you say we were looking at? How about we trial that first?
We all too often spend time and effort changing or developing advanced features that might be of use one day without even understanding what is already functional and useful in the tools we acquire. We define over-engineered reports to then hear users complain about the lack of clarity on what is needed to make them work. Don’t create the multi-function limo out of a van to transport your sheep: stop over-engineering and exploit what the tool offers to the full first.
1. Understand the concepts and the structure first
Begin the journey by defining the type of tool you require based on your objectives and select the one that closely matches your requirements. This will involve undertaking a deeper analysis of the core concepts of the tool to understand what they have been designed for. Map those concepts to the reality of your information system and the data you currently manage.
2. Start small but accurately
Once the tool has been chosen, define a clear scope to start with and stick to it during the initial project: whether your approach is broad and ‘shallow’ or specialised in details, define a scope you can realistically use to challenge the solution and engage future contributors.
Use a subset of high quality data to consolidate and validate the tool. More can follow if the results are satisfying.
3. Is more necessarily better?
If gaps between the solution and what you require of it exist, they will show during this first example consolidation exercise. List and prioritise those requirements but also discuss :
Whether it can be done in any other way than the way you have in mind
Whether you have the data necessary to make it work or have a way to collect this data accurately.
How you can keep it simple and intuitive for users. For instance if a report calculation needs to be complex, make sure users are guided to capture information it relies on. This can be done through the establishment and communication of standards.
Whether the tools are scalable and integrated with other tools to grow as your requirements expand in the future.
4. Involve the right people
Gather a small but strong core team involved in setting up the system, acting as ambassadors and reference points of the system for end users.
Inform end users from the start, communicate the project’s objectives and value, as well as their role in the quality of the outcome. This will help you understand what is of daily use and what is a bonus feature.
5. Speed matters
Find the right compromise between quality and speed: you may need to start with a smaller scope than what you had in mind to keep a reasonable timeframe and show results before expanding it. Communicate, engage the right people: that can (and will) take time.
Sure everyone wants the newest, the best, the shiniest new tools and technologies especially when it comes to supporting something as fundamental as your business, but in reality going over and beyond the required specification is not always the answer. Indeed future needs should always be taken into account but starting small and staying focused while selecting a tool is key. In today’s fast moving world, many tools are designed to be modular yet fully integrated, and scalable to provide agility and grow as your business needs change. These tools are essential in supporting your needs from the very beginning of your journey right until the very end.
... View more