How to do a high level IT review in under a day (Part 3)

Welcome to this, the last of a three part article on how to carry out a high level review in a day. The first part looked at how to break the problem down into more manageable chunks and then proceeded to review the Software aspects. The second looked at the Infrastructure considerations while this, the final part, reviews the Operations and Change aspects.

Operations

The first operational question is around availability. For example, what is the current uptime percentage and how are downtime windows communicated and approved? How these questions are answered will tell you a lot about how robust and mature the operational processes are.

The next area of questioning is about how the software is administered, by whom and under what circumstances. For example, if there is a CMS (Content Management System) then questions on what can be changed, by whom, when and how are all valid. This is important from not only a security view but also from an auditing/governance perspective.

If financial transactions are being handled then the Fraud processes need to be robust. Therefore, asking questions about those processes is key. It is worth ensuring that it is clear what financial rules and regulations the operational processes are designed to work with.

Finally. an understanding of how much Disaster Recovery is in place for the production systems is important. Depending on the risk profile, it may not be seen as critical but it is worth asking the question.

Operations Quick Check-list
- What is the current uptime percentage and how are downtime windows controlled?
- How does the administrator access the system to control it?
- Describe the Fraud processes
- Describe the current state of Disaster Recovery for all production systems

Changes

The final area to consider is that of changes to the system. This should cover bug fixes, small enhancements and upgrades. Understanding the process and who will carry out the work is essential, as is being clear on who approves the changes. There is a reason that change freezes occur around high value events ľ changes cause the majority of operational problems with a system. Therefore, understanding who tests what and when is of particular importance.

An interesting question to ask is how much of each stage is specified. The answer to this question permits an understanding of what methodology is preferred. Also worth asking is whether an IT roadmap exists or not? If so, how aligned to the end customer(s) is it?

Finally, is there a technology strategy for the software and its platform?

Changes Quick Check-list
- How often can or would the software be enhanced or upgraded?
- Who tests what and when do they test it?
- How much of each change is specified
- Does an IT roadmap exist?
- What is the technology strategy?

This completes this three part article and as you can imagine, only scratches the surface of this wide ranging and challenging topic. Depending on the situation, some aspects will be more important than others. For example, if the software is not going to be hosted by the provider then the Infrastructure considerations are clearly not as important.

I hope that you found this section of the article interesting and please feel free to contact me via the Contact Us page (here) if you have any questions.

Thanks

Peter Groom