APPENDIX A
THE BOARD REPORT

Alas, there is no ‘one-size-fits-all’ report that will work perfectly for all governing bodies. The type and length and format of the report will differ depending on the size and culture of the organisation, and the nature of your business and the perceived dependency on IT systems. By way of consolation, here are some questions to assist you with developing a suitable report for your organisation, assuming that you are starting from scratch and that you are not currently reporting through to the board.

First, you need your board sponsor to suggest the favoured presentation format for reports and the favoured way of viewing papers: online on a screen (for viewing on a desktop, smart phone or on a tablet), and/or printed (colour or black and white, and landscape or portrait format)? Do the board prefer data presented as spreadsheets (lots of numbers) or as pie charts (graphical view of data)?

Once you have these questions answered, and you have seen an exemplar board paper to work with, you will be ready to put something together.

Your one-page summary for your graphically minded board could be a set of pie charts showing your financial position, risks and risk classifications, performance information across your IT-enabled services, and a timeline showing planned deployments for major projects. If you have a spreadsheet-minded board, then you will most likely find that they do not feel that they require a one page graphical summary, but keep the report as short as possible.

The board will want a straight-forward, clear presentation of the facts, but remember that the information does not need to be dumbed down to fit on the page, and it is possible to present complex data in a clear format.

Generally (and we are talking very generally here), the board will want to see an IT update on:

• the financial situation (P&L, actual vs. budget, cash flow, capital expenditure and so on);
• stakeholders (personnel, internal and external customers and users);
• performance, availability and continuity of services and capacity planning;
• legislative considerations (licensing, compliance requirements and so on);
• risks, and security and privacy considerations;
• strategy and planning in progress with associated forecast budgets and in line with technology trends;
• major programmes in development and major programmes that have just gone into production.

As you can see from the above list, it should be relatively easy to report against the six principles listed in 38500 and to provide supporting graphs or spreadsheets so that the board can build up a pattern of activity and can identify progress across the different areas. Use the principle names as headings for your report and everything should fall into place nicely.

Do not fall into the trap of making each report look like the report before to the point where you omit to report on annual or infrequent activities, such as your disaster recovery exercise.

CASCADING BALANCED SCORE CARD EXAMPLE

The balanced score card traditionally groups four types of activities for reporting purposes, so pick four areas that are most pertinent to the running of your organisation, or try and bundle the six principles across four headings as I have below.

Starting from the top – identify what the board want to see. Now work out what data has to be collected at the management layer to provide this information. Now we know what the management layer need to report on, we can work out what data needs to be collected at the operational layer. The resulting cascading score cards could look something like Figure A.1:

Figure A.1 Cascading balanced score cards in action