When the requirements specifications are written support staff aren’t normally considered as users and this can lead to missed opportunities to minimise future support costs.

In a non-Maximo case a support team was stuck dealing with a proprietary file format that required complex and time consuming transformations before it could be used by a supplier. If their requirements had been captured then it should have been possible to remove that requirement or push the transformation work onto the supplier.

Never take the attitude “we will wait for the project team to hand over the system before support get involved”. That attitude means that the opportunity to gain valuable experience can be lost and could lead to problems being discovered after the project team have left.

If your support team hasn’t been included as users then:

• Warn the project team about known problems and/or periods of high transaction rates – It could help them avoid problems during bubble support
• Think about areas that generate lots of helpdesk calls and check if the design considers these elements – Even a small change like populating a searchid to an interface can make a massive difference when trying to debug problems with that interface. See this webex for integration related support tips
• Take any opportunity to learn about new support features and explore new processes – you may find messages that you can suggest modifying as described here e.g. to add in the siteid / recorded to a log message that the project team will see during the testing
• Spend time with the project team to gather as much information as possible – Consultants are often happy to demonstrate their expertise
• Raise PMRs for the project team - This will give you an invaluable insight into the debugging processes and the system’s problems
• Make time to read the logs from the testing – as I’ll explain in a later post messages project pressures mean these can be overlooked
• Always investigate how you are going to trace the flow of messages between the systems and what the message contents are.
• Ask if there have been intermittent failures e.g. JVM crashes or failures

Release handover

Hold handover meetings with the project team.

Ensure that the handover meeting covers at least:

• Details of the features / changes
• Questions about how problems were identified/resolved and any new processes

Use my article here as a reference point about the factors to consider.