Strategy – Q3: What do we need to achieve and what direction must we give to delivery partners?
The strategy question focuses around getting more granular outcome statements from all the stakeholders and defining the high-level functions and information that will support them.
Workshopping through these statements with the “End User” (consumer/customer, the operator and maintainer) is an important way of driving out their needs. Be careful to have the correct people in the room, for example a maintenance manager won’t necessarily understand the actual detailed task, but they will have in depth knowledge of how to schedule and budget for it.
A good methodology to use when looking at the outcome statements is the 3-column deduction.
Listing the statements generated during the workshop in the left-hand column, then asking the question “so what?” this will tell you what that means to the Information Management team.
Then ask, “so what?” again to list out the required deliverables in the right-hand column.
As well as the more detailed end user requirements, it is during this question that the Information Management (IM) team should work with the chosen financial and insurance companies to identify what information they require to monitor during the CAPEX lifecycle to reassure them that risks are being mitigated.
A good simile of this is when a learner driver starts out, insurance companies give them a black box full of sensors to put in the dash of the car, this collects data about how much of a risk they are through understanding breaking, accelerating and speed.
Both the financial and insurance companies will define a set of data that they would like to live monitor, showing them the risks, the delivery partners are taking. This may lead to cuts in interest rates and also insurance premiums.
Functional Information Requirements
The leap from Organisational Information Requirements to a highly detailed Asset Information Requirements can be a daunting one. Whereas an owner might have many thousands of different types of asset at element level, they will probably have less than 100 sperate high level functions.
So, a midway step will be to create a Functional Information Requirements package. This will list out the major asset functions required to support your business outcomes and detail the information required to define the function, measure its performance and set the levels which will indicate that it is no longer delivering what was intended.
Each of these Functions can then be linked down through the asset systems that support it to the element level later, but this set of information will help the business to understand how to monitor existing assets and also how to start procuring new ones.
When looking at the bigger picture, the customer riding on the railway does not need to know about the individual asset but does need to know that the overall function is achieved. For example, I don’t want to know about a specific diffuser, but I do need to know that air conditioning as a function is working!
Remember back when we looked at our OIRs, we defined Outcome Statements that each business department was a stakeholder in delivering. Now the focus is on the functions that will support that success. What functions are required to deliver that outcome and what information is needed to measure and monitor their performance?
Once this has been done for your existing portfolio of assets, then the chances are this set of requirements are 80% written for your new projects and can be used many times over!