Spreadsheet Guidelines_20130618_EuSpRiG

Spreadsheet Documentation

Andy Wiggins MSc FCCA

First version: 16th June 2011 Revised for EuSpRiG: 18th June 2013

This paper was originally produced for consumption within two UK life assurance companies The original concept was to demonstrate to users that spreadsheet documentation, to an acceptable

level, is achievable and that it need not be too onerous. In my view, any organisation adopting these suggestions should ensure that they are not seen as rules but only as guidelines.

The paper has been considerably restructured for its presentation to EuSpRiG.

Spreadsheet Guidelines_20130618_EuSpRiG.doc 14-Aug-2015 16:33

of 57

Contents Introduction ............................................................................................................................................ 3

Background ............................................................................................................................................. 4

History ..................................................................................................................................................... 5

Who Should Document and When? ....................................................................................................... 7

What to Document?................................................................................................................................ 8

Where to Document ............................................................................................................................. 10

Document the type of spreadsheet ...................................................................................................... 11

A proposal for embedding documentation within a workbook ........................................................... 13

Construction Proposals ......................................................................................................................... 22

Recommendations ................................................................................................................................ 25

Summary ............................................................................................................................................... 28

Appendicies ........................................................................................................................................... 29

Development Methodologies ........................................................................................................... 29

Unified Modeling Language .............................................................................................................. 32

How does the spreadsheet fit? ......................................................................................................... 35

Making Code Work ........................................................................................................................... 37

Criticality and Complexity ................................................................................................................. 41

The Input/Output Process................................................................................................................. 42

Credit Suisse .................................................................................................................................. 44

Principles and Standards for documenting an Internal Model. ........................................................ 45

True Stories ....................................................................................................................................... 51

Definitions ......................................................................................................................................... 54

References ........................................................................................................................................ 55

Other Useful References ................................................................................................................... 56


of 57

Introduction Today many businesses rely on reports or information produced by personal computer applications

such as Microsoft's Excel. As a tool it's a very handy product, sometimes described as the Swiss Army

Knife of business. Because of its adaptability it has found its way into all corners of business life. But

like all tools it has to be used properly, and if it's not, then your business could be at risk.

I have been specialising in spreadsheet development for a number of years. I have worked in many

organisations but I have never seen any generally accepted standards for documenting small system

developments, such as those based on Excel and Access. As a matter of course I have documented

my work and this paper will describe some of the methods I have used and others of which I am

aware.

Many organisations recognise the lack of documentation relating to spreadsheets within both the

development and production stages. Regulators are now demanding that all processes, including

those involving spreadsheets, are documented to an adequate standard. Sarbanes Oxley requires

that all spreadsheets should have sufficient documentation to enable an independent person to

understand and use the spreadsheet model. Whilst the United Kingdom’s (UK) Financial Services

Authority1 (FSA) is requiring documentation to a level so that “a knowledgeable, professional,

financially aware person with ... modelling experience [could rebuild its] model based on the

documentation” [Ref001].

Documentation is not a popular topic within the spreadsheet domain. This article will make some

suggestions as to why that might be the case.

To aid understanding of the background some of the available methods of documenting software

are discussed in the appendices.

This paper will address the issue of documentation with proposals to help improve the current

culture. It will suggest a set of core proposals on how to document spreadsheets which can be

extended as required. The initial research has indicated that there appear to be no generally

accepted methods in existence, so this paper brings together some of the more popular suggestions.

1 From 1-Apr-2013 this becomes the Financial Conduct Authority (FCA)


of 57

Background

“Spreadsheets offer the flexibility and ease of use of a desktop application, combined with the

power to perform complex data analysis. As a result, spreadsheets are used to support critical

business processes in most organizations ... research indicates that over half of financial

management reporting is performed with spreadsheets. Despite this, a disparity exists between the

importance of spreadsheets to business processes and the level of corporate resources devoted to

spreadsheet development, testing, and maintenance.

Organizations today are under considerable regulatory pressure to ensure that financial reporting

processes are both transparent and well-documented. Three visible examples of such legislation are

the Sarbanes-Oxley Act (United States, 2002), the Data Protection Act (European Union, 1998), and

the Basel Capital Accord (Basel II, 2006), which together impact most publicly-traded companies

around the world.”

Microsoft 2007 [Ref002]

Spreadsheets have never been well-documented, but now that regulators demand it industries and

organisations are beginning to take the subject seriously. The End User Computing (EUC) issue has

come to the fore after the introduction of compliance legislation such as SOX and the heightened

vigilance of auditors [Ref003]

Through Solvency II, the need for strengthened requirements on capital adequacy and risk

management, the insurance industry is being expected to ensure that all its processes and

procedures are adequately documented [Ref004] so that “a knowledgeable, professional, financially

aware person with capital modelling experience [could rebuild its] model[s] based on the

documentation”. The FSA does not define the limitations of the models, so it would seem to be fair

to proceed on the basis that anything impacting on the models is within the FSA’s scope.


of 57

History Computer based spreadsheets have been existence since the 1960s , but have only become popular,

and generally accepted, since Visicalc made its debut on the Apple II personal computer (PC) in 1979

[Ref005]. Released in 1983, Lotus 123 became the world’s most popular spreadsheet program. In the

1990s, with the introduction of Microsoft’s Windows 3.1, Excel eventually took over as the dominant

spreadsheet product. It would appear that the dominance of Excel might now be being threatened

by products such as OpenOffice and Google’s Spreadsheet.

However, the spreadsheet has been in existence, as a paper based product, for longer than any of

the computer based products. In the UK it was called “Multi-column analysis paper”. In the USA it

was called a “spreadsheet” hence the name of the computer based version.

Most accounting systems (computer and manual) record the majority of an organisation’s

transactions; however there has always been a need for additional analysis of the figures. That is

why the paper spreadsheet was found mainly in the accountancy department and why, when micro-

computers became available, Visicalc and Lotus 123 were taken up with enthusiasm by accountants.

Accountants were able to develop paper-based spreadsheet analysis because most of the time the

requirement would fit onto the grid. They were able to adopt a similar approach when they were

given computer based spreadsheets, with the added bonus of immediate visual feedback. The use of

computer spreadsheets was so similar to paper spreadsheets that the need for a formal approach to

construction, similar to one that might be taken by their information technology (IT) colleagues, was

not required. There was no need for any formal process to approve the development because the

cost was likely to be the same however the task was completed, either on paper or computer. The

PC had the added, and perceived, advantages of neatness, accuracy and the ease of repeatability

through the ability to clone the process over subsequent time-periods.

This position has evolved into the situation we see today where most spreadsheet development

arises from a need without any formal approval process being employed. Some of the research

suggests that the balance of formal development control as opposed to the ease informal

development could be one of cost.

One significant difference has occurred between the way accountants perform analyses, pre and

post personal computers. Pre PCs, several people might have been involved in a process, and this

was called the separation of duties. Each part of the process would have been balanced (checked)

before being passed to the next sequence. Post PCs most of these double-checks disappeared.

Accountants relied on the PC to ensure accuracy. What this did not allow for was the accuracy of

input of the original data, the calculations and the construction of the reports.

The traditional divide between end-users and IT professionals has become blurred as user-friendly

tools, such as the spreadsheet, have allowed end-users to create their own applications [Ref006].

With this blurring, the former paper-based approval and checking processes have been used as the

model for computer spreadsheets and one of its facets has been, “no documentation”. Traditionally,

the methods of training others have been one of “father to son”. The scale of some end-user


of 57

developments, and organisations’ reliance on them, is now requiring a rethink as to how they should

be documented.

As Perry [Ref007] says, “Spreadsheets fall into the realm of end user developed applications and are

often absent from the proper safeguards and controls an IT organization would enforce for

enterprise applications.” With which Baker et al [Ref008] appear to concur, “... researchers, auditors,

and consultants frequently express the concern that spreadsheet use defies the norms of discipline

that can be found in other business activities.”


of 57

Who Should Document and When? With spreadsheets, all users are simultaneously owner, developer, programmer, tester, and user

[Ref009]. If the spreadsheet owner is not the developer they might not fully understand its sources,

calculations and outputs [Ref009].

Accepting that every application (spreadsheet) has an owner, who might not be the person who

wrote it, or who now maintains it, is the starting point for documentation. The owner, who is

probably a department manager, is ultimately responsible for its use, maintenance and the quality of

its output. However, although that person might not be the best placed to document the

application, they are best placed to delegate that to a responsible person; to paraphrase the FSA, “a

knowledgeable professional”. In all probability, that person will be the one who has made the latest

amendments to the spreadsheet.

Documentation should be updated whenever a change to the underlying structure is made. This

might be a change to VBA code, to sheet based formulas, to range names, to the data sources used,

to name but a few.


of 57

What to Document? There appears to be no general consensus on what to document, but a few papers do give

indications.

One of the more often quoted is Butler’s paper [Ref010]. Perhaps the reason it’s quoted so often is

because Ray Butler was, at the time, part of the UK’s Customs and Excise (Now part of HMRC) team

that audited client accounts and, therefore, some of their spreadsheets. In the box, below, is

reproduced an extract from that paper detailing the level of documentation they expected to find.

Has the developer documented the spreadsheet, to make clear :

what it’s for;

what it does;

how it does it;

what assumptions were made in its design;

what constants are used and where they are held;

who developed it;

when it was developed;

when and how it has been changed since being brought into use;

the presence and purpose of any macros?

His comments on why he expected this were:

The better the documentation, the less scope there is for error or misunderstanding between the developer and the user.

A review of current documentation will help in risk assessment ...

A good practice in design is to include the documentation as part of the workbook on a separate sheet.

... consider the quality as well as the existence of documentation in your risk assessment.

Morison and Jordan [Ref011] said that the required amount of documentation related to:

The purpose of the spreadsheet

The users of the spreadsheet

Whether it will be used on-line or must be understood from hard-copy

The consequence of errors and the need for validation


of 57

and that the following should be included in the documentation.

Title

Statement of purpose

Scope and limitations

Author’s name

Date Witten

User Instructions

Variables Used


of 57

Where to Document The previous sections have expressed some ideas on defining the importance of a spreadsheet, its

structure and the elements that might be required in any formal documentation process. This

section will explore some ideas on how this documentation might be achieved.

Here are a few ways to document a spreadsheet:

Within the spreadsheet.

In a document as hardcopy.

In an on-line document.

The storage of documentation within a spreadsheet

The main advantage of this method is that the documentation travels with the spreadsheet. It also

means that spreadsheets might be larger than they otherwise need be. As most documentation will

be 99% text it should have little or no impact on a spreadsheet’s recalculation speed.

Hardcopy document

This can be read off-line and is easy for users to make their own additional notes as required. The

user can’t always be sure that this is the latest version and contains all necessary amendments for

recent program updates. It can get lost.

On-line document

This requires a computer to be read, or to download. It should be the latest version of the

documentation containing all the latest amendments for program updates.


of 57

Document the type of spreadsheet Most businesses tend to have a mixture of spreadsheets.

Both Burdick [Ref012] and Compliance Week [Ref013] identified three types of spreadsheet:

Burdick Compliance Week

Critical Level 1

Material Level 2

Immaterial Level 3

Burdick was more concerned with the “dollar” value impact, whereas Compliance Week was testing

the importance to the organisation.

This paper suggests the use of:

Risk Rank Magnitude

A - Critical B - Material C - Ad hoc

Complexity

1 - Advanced High High Low

2 - Intermediate High Medium Low

3 - Elementary Medium Medium Low

4 - Simple Medium Low Low

As part of each spreadsheet a field labelled “Classification” could hold a value based on this matrix,

for example, A1, for a critical-advanced spreadsheet to C4 for an ad-hoc-simple spreadsheet.

Magnitude:

Critical: Financial regulators would consider them critical to the stability of financial markets.

Any system whose function is critical to running of business.

Material: Important to the business, but will not materially affect it, or the financial markets,

if it becomes unavailable.

Ad hoc: Used for :

o a specific problem or task,

o has no long-term value or

o will not affect the business or financial markets if it becomes unavailable.

Complexity:

Advanced: Combination of VBA and spreadsheet functionality that would normally be

considered beyond the scope of understanding of a local user.


of 57

Intermediate: Use of either or both VBA and spreadsheet functionality that would be

expected from a proficient local user.

Elementary: Use of functionality expected from a competent local user. It might include

some simple VBA, such as recorded macros.

Simple: Understandable by those with basic spreadsheet training. It will not include any VBA.


of 57

A proposal for embedding documentation within a workbook

User Guide (1)

This section gives an overview of the documentation that might be embedded within a workbook.

It covers three sheets that could be stored as a template, as part of the Microsoft Office installation,

or be copied in from a network source such as Sharepoint. It can be used as a new workbook, when

commencing new applications, or it can be added to existing applications by copying the

documentation sheets into it.

Highlight the sheets you want to copy

Right click on your mouse

From the menu, click “Move or Copy”

Select the book where you want the sheets

Click “OK”

The three sheets do not contain any macros. They do contain two formulas that link the workbook to

its path and to an external documentation workbook (if it exists).


of 57

The first sheet asks for, up to, 12 pieces of information and allows you to classify the workbook (see

above). The information relates to what the workbook does together with whom owns it and by

whom it was developed. The sheet is called “01 – Overview”.

The second sheet, called ” 02 - Processes”, which suggests a layout that can be used to give basic

documentation about the inputs, processes and outputs. It consists of five columns:

1. Indicates whether its describing an input, process or output,

2. Type: a general description of the data

3. Source: The source of the data

4. Target: Where the data is used


of 57

5. Method: How the data is obtained and how it’s input or attached to the workbook.

The final sheet, called “03 - ChangeLog”, is maintained by whoever makes changes to the structure

or code of the workbook. It consists of five columns:

1. Date: the date of the change(s).

2. Version: the new version number applied as a result of the change(s).

3. Name: The name of the person making the change.

4. Sheet / Mod: The name of the sheet or module where the change was made.

5. Notes: Description of the change.


of 57

The sheets are numbered from 01 to 03. It is suggested that we consider numbering all sheets in

order to describe the process flow through the workbook (inputs having lower numbers, rising

through calculations and moving towards outputs). This was particularly important in older versions

of Excel, when recalculations were carried out on an iterative sheet-by-sheet basis.

This is by no means exhaustive. If a spreadsheet is very critical, more documentation might be

required to satisfy the regulatory authorities, such as an external document giving a more detailed

view of the construction and process.

User Guide (2)

If appropriate, the use of a flow-charting product or similar techniques could be employed.

Below is an example created using Excel. Some Excel shapes can be hyperlinked to a place within the

workbook or an external address. In this example, the shaded shape indicates the application, and it

is hyperlinked to a Word document which could be the external documentation for the file. Each of

the shaded region’s process boxes is hyperlinked to the sheet to which it relates. The boxes outside

the shaded region indicate the inputs and outputs. These boxes can also be linked to macros.

User Guide (3)


of 57

This is a detailed guide giving step-by-step user instructions to the process, possibly employing ISO

9000 standards (see appendix).

Technical (1)

This should be an overview of the spreadsheet’s construction. It might include details the Excel

features used, probably on a sheet-by-sheet basis. It should also include flow diagram(s) where

appropriate.

Below is an example of documentation output from XLAnalyst by Codematic Ltd. It has checked for

the use of various Excel features and noted their locations.


of 57

As an extension of this idea, a matrix could be included that indicates the use of Excel’s features

within each sheet. The list, in the left hand column, could be extended as required to encompass the

features used.

Column1 04

Flo

w C

har

t

11

Do

wn

load

Dat

a

12

Lin

ked

Dat

a

21

Cal

cula

tio

n

31

Re

po

rt 0

1

32

Dat

a Fi

le t

o G

rou

p A

Cs

External Links a a

Hidden rows or columns a

Conditional Formatting a a

Pivot Tables a

Array Formulas

Nested IF

SUMIF

SUMPRODUCT a a

INDIRECT a

Database Functions

Number of formulas 999

Technical (2)

Overview of any code used. This can extend beyond VBA (Visual Basic for Applications) and where it

does this should be noted.

Process flows should be noted, especially where they are linked to control mechanisms, such as

menus, toolbars, shapes or ribbons.

Technical (3)

Detailed description of code used, including flow diagrams.

If Visual Basic for Applications (VBA) is used, then the code should be commented. If it is possible,

the modules should also be given some numeric identity to indicate the order in which they are

used. VBA modules, however, cannot begin with a number so a prefix, such a reference to the

workbook name, is required.


of 57

General guidelines for VBA modules:

Each module should contain a distinct part of the process.

All Subs and Functions should contain a header.

All code should contain in-line comments, with the aim of making the code self-

documenting.

Indent code to emphasise the process flow.

Leave white space.

Do not leave “commented” code without good reason.


of 57

Another example of code documentation; this was part of a review for a code documenting product

called “Project Analyzer” (http://www.aivosto.com).

Source: http://www.dailydoseofexcel.com/archives/2007/12/13/vba-code-documenting-tools-

project-analyser-and-visustin/

Option Explicit

Sub GetFilesInDirectory(ByVal sDirToSearch As String, colFoundFiles As Collection)

'-------------------------------------------------------------------------

' Procedure : GetFilesInDirectory Created by Jan Karel Pieterse

' Company : JKP Application Development Services (c) 2006

' Author : Jan Karel Pieterse

' Created : 04-10-2007

' Purpose : Retrieves all files in sDirToSearch, stacks matches into

cLookForFIles

'-------------------------------------------------------------------------

Dim NextFile As String

Dim lCount As Long

Dim sFileName As String

Dim sFileSpec As String

Dim lFoundMatches As Long

Dim oCtlNew As CommandBarButton

Application.EnableCancelKey = xlErrorHandler

If Right(sDirToSearch, 1) <> "\" Then

sDirToSearch = sDirToSearch & "\"

End If

NextFile = Dir(sDirToSearch & "*.xls")

Do Until NextFile = ""

If Err.Number = 0 Then

If TypeName(oObj2Add2) Like "Command*" Then

Set oCtlNew = oObj2Add2.Controls.Add(msoControlButton, , , , True)

oCtlNew.Caption = NextFile

oCtlNew.OnAction = "OpenFileFromMenu"

oCtlNew.Tag = sDirToSearch & NextFile

Else

AddFile2Wizard oObj2Add2, NextFile, sDirToSearch

End If

End If

NextFile = Dir()

Loop

On Error GoTo 0

TidyUp:

Exit Sub

End Sub

Source: http://www.exceluser.com/explore/questions/vba_textcols.htm

Option Explicit

''======================================================

'' Program: ParseText

'' Desc: Reads a text file into a variable then

'' writes it into a row, n chars at a time

'' Called by: user

'' Call:

'' Arguments:

'' Comments: Written quickly. No error-checking.

'' Changes----------------------------------------------

http://www.aivosto.com/


of 57

'' Date Programmer Change

'' 6/14/06 Charley Kyd Written

''======================================================

Sub ParseText()

Dim sText As String, sFile As String

''Get the full path to the source file

With ThisWorkbook

sFile = .Names("SourcePath").RefersToRange

If Left(sFile, 1) <> "\" Then sFile = sFile & "\"

sFile = sFile & .Names("SourceFile").RefersToRange

End With

''Get the full text string from the text file

sText = GetText(sFile)

''Remove all nonprintable characters from the text

''Comment out if the characters are wanted

sText = Excel.WorksheetFunction.Clean(sText)

''Write to the workbook

WriteToSheet sText

End Sub

Other Documentation

During construction, embed notes using, for example, text boxes or cell comments. These

should be useful to both the developer and the users.

Cell comments

Styles

Defined Names

Informal: No matter how good a systems manual or how good a text book might be, we all

tend to make our own notes. Or we might ask advice from a colleague, but never make a

note of the answer given.

Retrospective Documentation

The discovery of undocumented files impacting Solvency II, which have not been documented, might

require them to be retrospectively documented. Be aware that if, as part of that documentation,

sheet names are amended or changed, this might impact other processes within that workbook or

within linked workbooks.


of 57

Construction Proposals

Suggestions for Construction

Number tabs in processing order

Give tabs names that describe what they do – don’t leave them as Sheet1, Sheet2, etc.

Use range names

Make workbooks menu driven wherever possible; this leads the user through the process

and can aid the documentation process.

Unlocked cells / Locked sheets

Use of passwords: Workbook level, sheet level, VBA Project

Colour code cells / sheet areas / tabs

Give all sheets a footer: when printed it makes the source apparent to those who use the

data, such as auditors and regulators.

Structured formulas can help understanding and, therefore, aid documentation. This

method is particularly useful when unscrambling nested IF statements.

Produce a demonstration workbook showing the principles of formula constructions and

their operation.

VBA: Separation of code / small modules

VBA: Meaningful names for modules, code and variables.


of 57

Remember, there are lots of tools built into Excel that can aid construction, checking and

documentation:

Tools > Protection > Protect Sheet:

Format > Conditional Formatting

Data > Data Validation

File > Properties:


of 57

Here are some examples of papers that provide useful guides when constructing spreadsheets:

The New Guidelines for Writing Spreadsheets - John F. Raffensperger, Ph.D.

What we know about spreadsheet errors – Ray Panko 1998

Directory Naming

Make the directory name pertinent to the process. If it is a periodic process, for example, monthly,

then sub-folders using the year and date could be used, for example, 201005. Ensure the year comes

first and that month numbers between one and nine contain a leading zero. This will ensure they

sort into sequential order in Windows Explorer.

File Naming

Make the name pertinent to the process. If it is a periodic process, for example, monthly then

include the date in the file name, for example, MonthlyAccounts_201005.xls. Ensure the year comes

first and that month numbers between one and nine contain a leading zero.

Security/Access control

Directories: secured by department / by process

Consider using passwords on worksheets, workbooks and the VB Project.


of 57

Recommendations Based on the foregoing, the following recommendations are made in respect of documenting an

organisation’s spreadsheets that contribute towards the production of essential processes such as

monthly accounts:

1. All files should contain the sheets outlined in “A proposal for embedding documentation

within a workbook”.

2. The following should be kept in separate sheets:

Data.

Code.

i. As a guideline, if a formula seems too long then it probably is. Long formulas

should be split. This might impact on the processing time but could also aid

readability and understanding.

ii. Splitting formulas could make the transformation of the data, between

states, more transparent, again contributing towards understanding.

Reports.

i. Reports tend to contain some calculation. If this can be avoided, it should

be.

3. All sheets should be numbered in order to describe the process flow through the workbook

(inputs having lower numbers, rising through calculations and moving towards outputs). For

example:

“11 – Data”

“31 – Calculation”

“81 – Profit and Loss Report”

“82 – Balance Sheet”

4. Use “Styles” to describe some cell usage (see appendix “Suggestion for Styles and Naming”)

5. All VBA code should follow the general guidelines for VBA modules:

Each module should contain a distinct part of the process.

All Subs and Functions should contain a comment header.

All code should contain in-line comments.


of 57

Indent code to emphasise the process flow.

Leave white space.

Do not leave “commented” code without good reason.

6. Use VBA coding convention for variable naming (see appendix “Suggestion for Styles and

Naming”)

7. All VBA modules should be numbered, especially where they are processed in a particular

order, for example:

8. Use a process such as Six Sigma’s SIPOC (Suppliers, Inputs, Processes, Outputs, Customers).

9. Ensure compliance with any Finance Reporting & Controls Framework (FRCF) in place.

FRCF relates to the preparation of reliable financial reporting and preparation of

local and consolidated financial statements in accordance with IFRS and MCEV. FRCF

also ensures compliance with the requirements of the Sarbanes-Oxley Act 2002

(http://www.aviva.com/reports/2010ar/governance/corporate-governance-

report.html/).

10. Possibly adopt some of the UML methods such as “Use Cases” and “Sequence Diagrams” to

aid the description of the processes.

11. Pay special attention to any other internal documents that might inform your own notes.

12. As professional as we intend to be, it is easy to (unintentionally) lapse when constructing

spreadsheets. Accountants know this and that is why most companies will have an Internal

Audit (IA) function that will, in retrospect, check figures and calculations. Many financial

organisations also now have a Compliance Department that ensures rules, such as those

relating to Solvency II, are applied. There is no reason why the monitoring of spreadsheet

http://www.aviva.com/reports/2010ar/governance/corporate-governance-report.html/

http://www.aviva.com/reports/2010ar/governance/corporate-governance-report.html/


of 57

construction and documentation could not be placed in this regime. This will have the

following benefits:

It can act as a peer review of spreadsheets.

Give regulators confidence in this organisation’s process.

Help to ensure common standards are maintained across the organisation.

13. If an auditor can understand the documentation and operate the process then both Solvency II

and SOX requirements would appear to be satisfied.


of 57

Summary The spreadsheet is a broad product, and the ease of development has allowed many non-IT users to

create applications pertinent to their work. The ease of development has also encouraged many

organisations to use spreadsheets as mainstream tools within their processing environment. One

disadvantage that has evolved from this evolution is the lack of documentation that goes with

applications, even those written by professionals.

Legal and regulatory requirements, such as Solvency II, are beginning to change this view. Solvency II

will require that:

... the insurance industry is being expected to ensure that all its processes and procedures are

adequately documented [FSA - fs09_01.pdf] so that “a knowledgeable, professional, financially

aware person with capital modelling experience” could rebuild its “model based on the

documentation”.

Informal talks with users would indicate a consensus of opinion that the level of documentation

should be appropriate to the application. This view might not, in all cases, be sufficient for

regulators, therefore the classification proposal might be a more useful guide used when

determining the level of documentation that should be produced.

One area, that might deserve its own paper, is that of spreadsheet construction. Documentation

comes after the event; it would seem appropriate to consider guidelines on construction that would

aid in production and that might make the task of documentation easier.

This paper has tried to outline the current position and bring together some ideas that would go

towards, if not fulfil, requirements such as those for Solvency II. If you adopt this paper then please

regard it as a “living” document to be revised as your organisation’s “best practise” evolves, much

like the documentation produced for an application.


of 57

Appendicies

Development Methodologies

This section will look at various development methodologies and how they might be applied to the

spreadsheet paradigm. Pressman says [Ref014], “Unfortunately, even with the best of methods, the

problem is that the problem keeps changing.” And that probably underlines why the spreadsheet is

so popular, because it seems that no matter what the problem, a spreadsheet can deal with it; not

necessarily in the most efficient manner, but more often than not it’s the most effective manner.

Whatever methodology is used there are key questions to be answer [Ref014]:

What is the problem to be solved?

What are the characteristics of the entity that is used to solve the problem?

How will the entity (and solution) be realised?

How will the entity be constructed?

What approach will be used to uncover errors that were made in the design and

construction of the entity?

How will the entity be supported over the long term, when corrections, adaptations and

enhancements are requested by users of the entity?

The analysis should achieve three primary objectives:

Describe what the customer requires

Establish the basis for the creation of a software design

Define a set of requirements that can be validated once the software is built.

Linear Sequential Model

The Linear Sequential Model, more popularly known as the “Waterfall Model” (originally proposed

by Royce [Ref015]), is now one of the more popular methods used, especially for large projects

where once designed there is little or no room for further change. It is worth noting that Royce’s

original model did have a feedback loop.


of 57

The model has the following stages:

Requirements specification

o Requirements are captured and set in stone.

Design

o A "blueprint" is drawn up for the developers to implement.

Implementation

Integration

Testing

Installation

Maintenance

Source: http://www.selectbs.com/adt/analysis-and-design/what-is-the-waterfall-model

Spiral Model

Originally proposed by Boehm, it is an evolutionary software model that couples the iterative nature

of prototyping with the controlled and systematic aspects of the linear sequential model.

http://www.selectbs.com/adt/analysis-and-design/what-is-the-waterfall-model


of 57

WINWIN Spiral Model

Again devised by Boehm, but with more emphasis on addressing customer communication. The

name comes from both the developer and customer striving to produce what is wanted within

realistic and achievable budgets and deadlines, which is a “Win win” situation.

The new model adds front-end

activities (blue) that show where

objectives, constraints, and

alternatives come from. This lets users

more clearly identify the rationale

involved in negotiating win conditions

for the product.

Prototyping Model

Customers usually define only the general objectives of what they want. The developer has to take

these and produce something for the customer to evaluate. The prototypes aid in the development

of the requirements as well as the final product. Brookes [Ref016] suggests that such systems are

barely usable and should be thrown away in favour of a refined solution. However, he also notes

that customers now see something that works and might insist on it being retained, without realising

the prototype is probably held together with string and good will.

V Model

The V development model can be considered as an extension of the Linear model. Its main benefit is

in how it demonstrates the links between the various phases from original conception to going into

operation.

Source: http://softwareandme.files.wordpress.com/2009/10/sdlc_v_model.gif

Accessed: 6 July 2010

Chaos Model

http://softwareandme.files.wordpress.com/2009/10/sdlc_v_model.gif


of 57

Raccoon [Ref017] suggests a model that describes, ”software development as a continuum from the

user to the developer to the technology”. The process becomes iterative as each stage of the

process returns to itself. It may help to explain why the production of software can seem so

unpredictable.

Rapid Application Development (RAD)

RAD emphasises short development cycles enabling a development team to produce a product

within a relatively short time, say between 60 to 90 days [Ref018]. Kerr [Ref019] identifies the

following modelling phases: business, data, process and finally, the application generation.

Unified Modeling Language

The Unified Modeling Language (UML) is a standardised component-based series of methods that

can be used to aid in the definition of the components and

interfaces that help to build a system. Using a scenario based

paradigm, It brings together the parts of a system and couples them in a view of what form the

eventual system might take.

UML is the based on the work of James Rumbaugh and Grady Booch. Later, they were joined by

others including Ivar Jacobson, Magnus Christerson, Patrik Jonsson and Gunnat Overgaard. UML

was formally adopted by the Object Management Group (OMG) in 1997.

It has various modeling approaches such as:

Use case models show how the actors interact with the various parts of the system.

Modeling follows the American spelling!


of 57

Source: p620 UML Superstructure Specification, v2.3

Sequence diagrams showing how actors and parts of the system, such as screens, interact in

sequence.


of 57

Component diagrams that describe how the various components of the system interact with each

other.


of 57

How does the spreadsheet fit?

The above are some of the classic software development models.

One of the characteristics of software development that tends to be disregarded, when considering

where spreadsheet developments should be placed, is that of the nature of the way computer

languages are dealt with after a program has been written.

There are two types of computer languages; those that are compiled and those that are interpreted.

A language that requires compiling is prepared using syntax specific to that language. The

program is run by another program that changes (or compiles) it into machine code, a form

that can be run by the host computer.

A language that is interpreted does not have to be compiled; it is directly interpreted by the

host computer. The advantage of using interpreted languages is that it can be tested

immediately; their main disadvantage is that they tend to be slower than compiled

languages.

Excel and VBA are interpreted, that is to say, the results are immediate. It is in this context that they

have found their niche within the business community, especially with accountants. For accountants

the spreadsheet was able to take the place of analysis paper. It gave them more accuracy and a

faster turn round during their regular accounting cycles. Accountants were able to produce their

figures and reports using spreadsheets. The occasional errors seemed to be acceptable and in-line

with errors that might have passed through the system when the same calculations were paper

based.

Spreadsheet programs entered business (mainly) through the accounting department. Many

accounting systems were paper based and the procedures for operating them were passed from

“father to son”. Also, as the basic concepts of accounts are international (for every debit there must

be a credit, and for every credit there must be a debit), the system of accounts production in one

organisation is very much the same as in all others.

The immediacy of spreadsheets for design and development is their strength and also, in terms of

control, their weakness. It is also probable that because of the way they originally entered into the

business community that the rigour of control (that might have been imposed had they entered via

the IT area), that persists today is lacking.

The immediacy and adaptability of the spreadsheet has encouraged its use a method of prototyping

possible software developments. When prototyping there is little, if any, need to document

something that might be thrown away if it does not produced the expected results. If the prototype

is seen as being effective it might be adopted as the solution.

It is, therefore, probably understandable why, even if it is not acceptable, that when a spreadsheet

product is adopted as the development platform of choice in a business area, documentation is not


of 57

always seen as a necessary part of the development. Neither is it seen as part of the permanent

documentation relating to spreadsheets that are part of the production process.

Historical note

Visicalc was the brainchild of Daniel Bricklin. He saw how much work had to be redone if a mistake

was made in a financial analysis. He specified a computer program that could alleviate the tedium of

re-casting such errors and, together with Robert Frankston, Visicalc was born. (Also see:

http://www.bricklin.com/history/saiidea.htm)

Daniel Bricklin had done some programming at Massachusetts Institute of Technology (MIT) using a

mainframe programming language called APL (that stands for “A Programming Language”). APL was

devised by IBM’s Ken Iverson as a mathematical notation that could manipulate large matrices of

numbers. IBM developed this into the mainframe language known as APL. APL is an interpreted

language and has been much favoured by mathematical modellers, such as actuaries (before

Prophet, Moses and Igloo were available), because of its immediacy.

APL programs are performed within a “Workspace” which is the same name that has since been

given to the programming area used by Prophet users.

In their advertising for Prophet, SunGard make direct comparisons with APL.


of 57

Making Code Work

Gomm’s Law, “In every successful program there is always one more bug.”

There are two types of code directly available to an Excel developer:

The functionality available within the worksheet environment, such as =SUM() and

=VLOOKUP()

The programming functionality afforded by Visual Basic for Applications (VBA).

Worksheet Environment

Within the worksheet there is scope for many errors. Much has been written on the subject of

spreadsheet errors and it probably deserves a paper in its own right.

Panko also stated that whilst most programmers spend 40% of their time testing, testing among

spreadsheet developers was extremely rare. He goes on to say that he believes “comprehensive

testing must be an ingredient in the mix”, but that little has been written about testing and that

what has been written has little detail, (That is “testing” as opposed to “errors”).

Wiggins (that’s me) says that testing is for wimps and that those who don’t test can enjoy the thrill

of wondering whether they’ve put their job, or even their organisation, at risk. I hope you appreciate

that this is irony.

Panko then goes on to describe the testing used in the V model. He then introduces another concept

that he refers to as ”eyeballing”, that is to say, testing the spreadsheet for reasonableness. This can

also include peer review, where a colleague is asked to test your work. Wiggins says (still me) that

eyeballing is a test accountants have been doing since before Bob Cratchit was a lad.

At the European Spreadsheet Risks Interest Group (EuSpRIG) conference 2007, Ray Panko

summarized existing data on spreadsheet errors [ Ref020]. Among the findings are the following:

Spreadsheets are widely used by many companies in financial reporting and other crucial

business areas.

Consistent with research on human error rates in other cognitive tasks, laboratory studies

and field examinations of real-world spreadsheets have confirmed that developers make

uncorrected errors in 2% to 5% of all formulas.

Consequently, nearly all large spreadsheets are wrong and in fact have multiple errors. Field

examinations of operational spreadsheets have confirmed this.

In fact, field audits have found that a large percentage of spreadsheets have errors that are

financially material [KPMG, 1988] or that could affect decisions [Coopers & Lybrand, 1997].


of 57

Excel has some internal error checking.

To aid tracing possible errors you can also use the auditing toolbar.

In Excel 2003 turn use View > Toolbars and turn−on the Formula Auditing toolbar.

In Excel 2007 they are found by using Formulas > Formula Auditing.

These tools can help trace the obvious errors. But what if one of your formulas has an error, for

example a “+” instead of a “-“? Test data produces a known result and should help show up these

types of errors and give the user confidence in the results.

Here is an extract from a large insurer’s expenses claim form that contains an error.

In cell CR33 the formula is: =SUM(CF33:CQ33)+BM33 In cell CR34 the formula is: =SUM(CF34:CQ34)+BM34 In cell CR35 the formula is: =SUM(CF35:CQ35)+BM34 In cell CR36 the formula is: =SUM(CF36:CQ36)+BM36 You can see the error in cell CR35. You just wonder how much they might have saved or overpaid as a result.

This structure also highlights a unique part of spreadsheet construction. In a “normal” program a

single formula might be used to iterate over a table of data. In a spreadsheet, the data might sit next

to the formula, but the formula will be copied against each line of data. When formulas are

replicated, in this fashion, it leaves room for subtle and inconsistent changes to be made. Such

changes will probably be unintentional (as in the example, above), but they do happen and can

affect the results.

Later there is a section on some of the horror stories that have caused many organisations financial

losses, including an error by NASA that caused a $644m loss. Obviously, if NASA makes mistakes

here, spreadsheets are beyond rocket science.


of 57

VBA Environment

This is probably an easier environment, than the worksheet environment, in which to test code as

much has been written on the testing of “normal” code structures.

There are two main types of routines that can be programmed:

Sub

Function

For these we can apply the V model approach of unit, integration and operational testing.

The primary goal of unit testing is to take the smallest piece of testable software in the application,

isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

Each unit is tested separately before integrating them into modules to test the interfaces between

modules. Unit testing has proven its value in that a large percentage of defects are identified during

its use.

Source: http://msdn.microsoft.com/en-us/library/aa292197(VS.71).aspx

Accessed: 6 July 2010

An example of VBA unit and stub testing is given in the appendicies.

The use of “Option Explicit” is recommended for all VBA code. This forces all variables to be

declared. This ensures that no renegade variables can creep into your code without your knowledge.

To ensure that “Option Explicit” appears in each module, in the Visual Basic Editor (VBE), from the

menu, Tools> Options and ensure that “Require Variable Declaration” is checked.

http://msdn.microsoft.com/en-us/library/aa292197(VS.71).aspx


of 57

A general consensus of opinion, taken amongst colleagues, is that VBA should be self documenting.

That is not to say that the developer’s additional comments are not required (they are), but that the

general layout, structure and format of the code should aid an outside party’s understanding. This, in

turn, will aid the discovery of any errors that might be present.

Data

The foregoing makes the assumption that the data, being used, is correct.


of 57

Criticality and Complexity

Burdick [Ref012] suggests that criticality and complexity should be two of the auditing measures

used when assessing the effectiveness of spreadsheet management. Critical, because it identifies the

importance of the spreadsheet to an organisation, and complexity because it can give an indication

of the level to which the spreadsheet has been written (for example, in the number of Excel features

used, especially those features that are infrequently found).

Here is a copy of Burdick’s criticality and complexity matrix:

Compliance Week (2006) published a paper on Spreadsheet Documentation. They identified three

levels of spreadsheet:

Documentation Level

• Level 1 – spreadsheets that are integral to the financial reporting process of the Company and its

subsidiaries.

• Level 2 – spreadsheets that are significant in size, used frequently and/or complex in nature, which may be

used for analytical tools, economic evaluations, modeling, budgeting, forecasting and reporting.

• Level 3 – spreadsheets that are ad hoc in nature, filling a one-time need, or relatively simple in logic.

Applied as a measure, it might help give a immediate indication, to management, auditors and

regulators alike, as to the spreadsheet’s relative importance within the organisation. Such a measure

would be subjective and would have to be kept under review.


of 57

The Input/Output Process

All businesses can be broken down into a series of building blocks based. At its lowest level, there is

the process. A process is a course of action intended to achieve a result [Ref021]. The process

receives inputs which it transforms and produces outputs. One, or more, of these basic processes

might come together to form a major process such as, for example, a department within an

organisation. A collection of departments come together to create the organisation. All of these

processes have a purpose:

(Diagram: Source [Ref021]. “Why?” is the strategic vision and “Output” is the requirement of

the “Why?”.)

The following diagram [Ref022] demonstrates the the fourth possible element, that of a

feedback loop which is a method of reviewing or changing the input depending on the output.

(Diagram: Basic Input/Output process with a feedback loop [Ref022])

If a spreadsheet is taken as one of these processes then it can be seen that the three building blocks

apply:


of 57

Inputs, which can be manual input, file links, data from other systems such as payroll.

Process: Transformation/Manipulation/Calculation.

Outputs, which can be reports or data feeds to other systems.


of 57

Credit Suisse

Below are extracts from an FSA action against Credit Suisse [Ref023]


of 57

Principles and Standards for documenting an Internal Model.

Here is an extract from a “Solvency II Business Requirements” paper.

Guiding Principles The ultimate objective is to produce a “documentation set” for the Internal Model in a condition that would allow a knowledgeable 3rd party to understand and, in principle, re-create it. The following are more specific guiding principles to be followed in documenting the Internal Model: 1. Pragmatism: There will be limited prescription as to format and style but suitable examples will be provided as guidance. 2. Reuseability: Existing documentation should be used wherever possible. This documentation will be improved where necessary. Also, a single document may be part of several “views”. The different views will be tailored, in depth and level of detail, to specific audiences, for example, senior management, users and IT. 3. Parsimony: The maxim “Less is more” should be used in determining the volume of documents to be included so that the documentation is clear and concise. 4. Simplification: Where many documents (but not too many !) exist to explain a concept or method, the use of a “narrative” document may be required to tie the others together and help readers navigate more easily. 5. Granularity: Detail of the documentation must take into account the level at which it is intended to be used. At present, these levels are Board, Group, Region and Business Unit.

6. Leverage: Where they exist, self-documenting features of the modelling platforms


of 57

VBA Documentation

Extract from : Financial modeling: using Excel and VBA By Chandan Sengupta [Ref024]


of 57

Other Products

“Excel VBA Code Documentor” is developed by Microsoft.

Source: http://excel-vba-code-documentor.software.informer.com/

No screen shots or further explanation seemed to be available.

Other tools:

VBA Language Specification

http://msdn.microsoft.com/en-us/library/dd361851%28PROT.10%29.aspx

Part of the Microsoft library: http://msdn.microsoft.com/en-us/library

VBA Programming

“Corporate VBA Standards For Excel Users Who Program”

Source: http://www.exceluser.com/explore/vbastds.htm

http://microsoft.software.informer.com/

http://excel-vba-code-documentor.software.informer.com/

http://msdn.microsoft.com/en-us/library/dd361851%28PROT.10%29.aspx

http://msdn.microsoft.com/en-us/library

http://www.exceluser.com/explore/vbastds.htm


of 57

Suggestion for Styles and Naming

(Source: www.BygSoftware.com)

Sheet Styles

Description Style

Input Formula Alternative formula Linked In Validation List

Text Byg_Input Byg_AlternativeFormula Byg_Input_LinkIn Byg_List

Turquoise abc Normal & format abc abc

Number Byg_Input_2Dec Byg_Normal_2Dec Byg_AlternativeFormula Byg_Input_LinkIn Byg_List

Borders - Grey 80% 1,234.56 1,234.56 1,234.56 123

Date Byg_Date Byg_Date_Formula Byg_Date_AlternativeFormula Byg_Date_LinkIn Byg_List

Date borders - Light Green 04-Mar-2009 04-Mar-2009 04-Mar-2009 04-Mar-2009

Normal Byg_Input_0Dec Byg_Normal_0Dec

1,235 1,235

Percentage Byg_Input%_2Dec Byg_%_2Dec

12.34% (12.34%)

VBA Naming

String Long Double Boolean

VBA - sub / function argument aStr_XXX aLng_XXX aDbl_XXX aBoo_XXX

VBA - sub / function internal variable lStr_XXX lLng_XXX lDbl_XXX lBoo_XXX

VBA module mStr_XXX mLng_XXX mDbl_XXX mBoo_XXX

VBA global gStr_XXX gLng_XXX gDbl_XXX gBoo_XXX

VBA - sub / function internal variable constants lConStr_XXX lConLng_XXX lConDbl_XXX lConBoo_XXX

VBA module constants mConStr_XXX mConLng_XXX mConDbl_XXX mConBoo_XXX

VBA global constants gGloStr_XXX gGloLng_XXX gGloDbl_XXX gGloBoo_XXX


of 57

VBA LayoutExample Layout for Unit and Stub Option Explicit

'' - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

'' Purpose : Output TEST results to the immediate window

'' Written : 21-May-2002 by Andy Wiggins, BygSoftware.com

''

Sub TEST_Byg_LastCell()

Debug.Print " - - - - - - - -"

Debug.Print " "

Debug.Print " ""R"", last row (including no argument given)"

Debug.Print Byg_LastCell("R")

Debug.Print Byg_LastCell("r")

Debug.Print Byg_LastCell

Debug.Print " "

Debug.Print " Anything else returns the last column"

Debug.Print Byg_LastCell("C")

Debug.Print Byg_LastCell("c")

Debug.Print Byg_LastCell("X")

Debug.Print " "

Debug.Print " - - - - - - - -"

End Sub

'' - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

'' Purpose : Returns the last cell, in use, on the active sheet

'' Written : 21-May-2002 by Andy Wiggins, BygSoftware.com

'' Notes : This could be split into two functions; for rows and columns

''

Function Byg_LastCell(Optional aStr_Rc As String = "R") As Long

With ActiveSheet.Cells.SpecialCells(xlCellTypeLastCell)

Select Case aStr_Rc

Case "R", "r"

Byg_LastCell = .Row

Case Else

Byg_LastCell = .Column

End Select

End With

End Function


of 57

ISO 9000

ISO 9000 is a family of standards for quality management systems. ISO 9000 is maintained by ISO, the International Organization for Standardization and is administered by accreditation and certification bodies. The rules are updated, as the requirements motivate changes over time. Some of the requirements in ISO 9001:2008 (which is one of the standards in the ISO 9000 family) include

a set of procedures that cover all key processes in the business;

monitoring processes to ensure they are effective;

keeping adequate records;

checking output for defects, with appropriate and corrective action where necessary;

regularly reviewing individual processes and the quality system itself for effectiveness; and

facilitating continual improvement

A company or organization that has been independently audited and certified to be in conformance with ISO 9001 may publicly state that it is "ISO 9001 certified" or "ISO 9001 registered". Certification to an ISO 9001 standard does not guarantee any quality of end products and services; rather, it certifies that formalized business processes are being applied.


of 57

True Stories

These are given as examples of errors that have occurred. Whilst documentation might aid

understanding and be an important factor for some regulators, these examples serve to highlight

some of the problems that can arise in this uncontrolled environment .

Black-on-black cell text format attempt to 'hide' data

http://www.smh.com.au/news/business/westpac-jumps-the-gun-on-

profit/2005/11/02/1130823280336.html

Westpac was forced to halt trading on its shares and deliver its annual profit briefing a day early

after it accidentally sent its results by email to research analysts. Details of the $2.818 billion

record profit result for the 12 months to September 30, were embedded in a template of last

year's results and were accessible with minor manipulation of the spreadsheet. (Some reports

indicated an employee had thought that a black cell background fill would hide black text.) Mr

Chronican said "It is not just one error, it is a compounding of two or three errors... We will

obviously be conducting a full inquiry to make sure it doesn't happen again."

Risk: public embarrassment, loss of investor confidence

Avoidance: User training on how to remove data properly

How easy it is to change a spreadsheet, how hard to do version control...

http://www.namibian.com.na/2005/October/national/05E0F49179.html

The Agricultural Bank of Namibia (Agribank) is teetering on the edge of bankruptcy. "There is no

system of control on which the auditors can rely nor were there satisfactory auditing procedures

that could be performed to obtain reasonable assurance that the provision for doubtful debts is

adequate and valid," note the auditors. Auditors found that its loan amount to the now defunct !Uri

!Khubis abattoir changed from N$59,5 million on one spreadsheet to N$50,4 million on another,

while the total arrears was decreased from a whopping N$9,8 million to only N$710 000.

Risk: loss of financial control

Avoidance: Change management, version control

Auditor's report : a checklist of testing and maintenance standards

http://www.fdicig.gov/reports01/01-025.pdf

Office of Inspector General (OIG) December 13, 2001 Audit Report No. 01-025 Audit of the Least

Cost Test Model of Federal Deposit Insurance Corporation (FDIC). "we concluded the model is

generally operating as intended. However, ... controls over access, software development, and

changes were weak." "no record that the software was tested ... not developed a system for

requesting, making, testing, and approving changes ... little security over the macros and

formulas" (Reference: OMB Circular A-130, Appendix III) "found compatibility problems" "The

FDIC no longer employs the DRS employees responsible for designing the spreadsheet, and no one

has documentation on how the spreadsheet was created in case modifications are needed" "some

of the formulas within the template had been overwritten"

http://www.smh.com.au/news/business/westpac-jumps-the-gun-on-profit/2005/11/02/1130823280336.html

http://www.smh.com.au/news/business/westpac-jumps-the-gun-on-profit/2005/11/02/1130823280336.html

http://www.fdicig.gov/reports01/01-025.pdf


of 57



Auditor's report : a checklist of documentation and change standards

http://www.anao.gov.au/WebSite.nsf/0/1EA061E6A929D67ECA256FBF00783027?OpenDocument The Auditor-General Audit Report No.38 2004-05 Performance Audit, Goods and Services Tax (GST) . To calculate GMA and BBA, Treasury uses a Microsoft Excel spreadsheet with 32 linked worksheets "The spreadsheet was developed in-house with limited resources and without adequate

consideration being given to alternatives. The resulting approach did not, in ANAO's view, adequately manage some important risks. ... difficult to navigate for the purpose of verifying that it is performing calculations correctly. ... developed in-house with limited resources and without adequate consideration being given to alternatives. ... ANAO was unable to locate any system documentation ... None of the present staff in the Unit was there when the spreadsheet was constructed. ... Repeated manual entry of the same data clearly increases the risk of errors. ...

shortcomings [in] managing the records that support the data ... an unacceptable level of risk

that staff responsible for updating the spreadsheet may inadvertently access an earlier version of the spreadsheet."



Spreadsheet penalties

August 12, 2002 - in a regulated industry, the process is as important as the product:

Source: http://tis.eh.doe.gov/enforce/eas/EA-2002-03WS.pdf

Preliminary Notice of Violation and Proposed Imposition of Civil Penalty $137,500 ... quality

assurance issues affecting nuclear safety surrounding the discrepant nondestructive assay (NDA)

data provided to Bechtel Hanford, Inc., in support of their decontamination and dismantlement

activities at Building [ ]. Contrary to the above, between September 1998 and May 2001, work

was not performed to established standards and controls using approved procedures. Examples

include the following

... the modification to the spreadsheet was not subjected to validation

... the revisions to the spreadsheet used in the [ ] NDA process were not uniquely identified and

labeled

... several deficiencies related to the use of NDA applicable spreadsheets

Risk: Fines and penalties

Avoidance: Document and archive your work

Rocket Science

http://www.gao.gov/new.items/d04754t.pdf

In 2000, NASA misstated its accounts by $644 million after using an ad-hoc spreadsheet

consolidation process, an error not found by its independent auditor.

Spreadsheets aren’t rocket science, but if NASA can send men to the Moon and make such huge

http://www.gao.gov/new.items/d04754t.pdf


of 57

mistakes in their spreadsheet programs, why should anyone else be expected to be any better?

(NASA Significant Actions Needed to Address Long-standing Financial Management Problems - Kutz

and Li 2004)


of 57

Definitions

Spreadsheet A computer spreadsheet program such as Microsoft’s Excel or IBM’s Lotus 123. The original spreadsheet products consisted of a single sheet. Today this has become a generic name that also refers to the multiple-spreadsheet paradigm. Excel refers to single sheets as “Worksheets”, and to the whole file as a “Workbook”.


of 57

References

Ref001 www.fsa.gov.uk/pubs/discussion/fs09_01.pdf, accessed 26th July 2011

Ref002 http://www.microsoft.com/download/en/details.aspx?id=11604, accessed July 2010

Ref003 Spreadsheets - Aiming the Accountant's Hammer to Hit the Nail on the Head - Alliy and Brown 2008

Ref004 Financial Services Authority - Insurance Risk Management- The Path to Solvency II - fs09_01.pdf

Ref005 Getting small- a short history of the personal computer ~ Abbate 1999 ~ 00784256.pdf

Ref006 End User Computing in AIB Capital Markets - A Management Summary - McGeady McGouran 2009 - 0909-2455.pdf

Ref007 Automating Spreadsheet Discovery and Risk Assessment - Eric Perry 2008

Ref008 Comparison of Characteristics and Practices amongst Spreadsheet Users with Different Levels of Experience

Ref009 Spreadsheet Management - Deloitte - cn_ERS_SpreadsheetMangt_030908.pdf

Ref010 SpACE-Methodology for the Audit of Spreadsheet Models, Developed by HM Revenue & Customs Audit Service, September 2007 http://customs.hmrc.gov.uk/channelsPortalWebApp/channelsPortalWebApp.portal?_nfpb=true&_pageLabel=pageVAT_ShowContent&id=HMCE_PROD_009443&propertyType=document, accessed July 2010

Ref011 Spreadsheet Documentation for Students and Engineers – Morison and Jordan - 2000

Ref012 Improving Spreadsheet Audits in Six Steps - Tim Burdick 2008

Ref013 Compliance Week, 2006

Ref014 Software Engineering – Roger Pressman

Ref015 Managing the Development of Large Software Systems - Winston Royce - 1970

Ref016 The Mythical Man Month - Brooks 1975

Ref017 The Chaos Model and the Chaos Life Cycle - Raccoon 1994

Ref018 Rapid Application Development - Martin 1991

Ref019 Inside RAD - Kerr and Hunter 1994

Ref020 Recommended Practices for Spreadsheet Testing - Raymond Panko 2007

Ref021 What is a Process - Northumbria University - Accessed 20100629.doc

Ref022 Design & Technology - Systems and production methods - BBC.co.uk - Accessed July 2010

Ref023 FINAL NOTICE - To - Credit Suisse International and Credit Suisse Securities - FSA 20080813 - credit_suisse.pdf

Ref024 15253251FinancialModelingbyChandanSengupta.pdf Source: http://books.google.com/books?id=mzrjIJE4_BAC&pg=RA3-PA457&lpg=RA3-PA457&dq=excel+%22documenting+vba%22&source=bl&ots=5-J7qdHqNY&sig=lkgPhRZgrKPMsTvWFQW6Csu9k0Y&hl=en&ei=nvkqTJj_LJf40wTNoaDqAg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBUQ6AEwAA#v=onepage&q=excel%20%22documenting%20vba%22&f=false

http://www.fsa.gov.uk/pubs/discussion/fs09_01.pdf

http://www.microsoft.com/download/en/details.aspx?id=11604

http://customs.hmrc.gov.uk/channelsPortalWebApp/channelsPortalWebApp.portal?_nfpb=true&_pageLabel=pageVAT_ShowContent&id=HMCE_PROD_009443&propertyType=document



http://books.google.com/books?id=mzrjIJE4_BAC&pg=RA3-PA457&lpg=RA3-PA457&dq=excel+%22documenting+vba%22&source=bl&ots=5-J7qdHqNY&sig=lkgPhRZgrKPMsTvWFQW6Csu9k0Y&hl=en&ei=nvkqTJj_LJf40wTNoaDqAg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBUQ6AEwAA#v=onepage&q=excel%20%22documenting%20vba%22&f=false






of 57

Other Useful References

Documenting Spreadsheets - Raymond Payette - 0803.0165.pdf

Spreadsheet_Documentation_Guide - AuditNet Org.pdf

It Ain't What You View, But The Way That You View It documenting spreadsheets with Excelsior, semantic wikis, and literate programming = Jocelyn Paine 0802.3478.pdf

Spreadsheet Documentation Policy.doc

Verifying Documentation Standards in Spreadsheet Analysis - LeBlanc and Galbreth - SSRN-id941709.pdf

Spreadsheet Control Marches Forward - Neff - 2298_Document.pdf

When does a spreadsheet become an application.doc

Spreadsheet Testing Presentation to ISACA Northern England 2004 - Patrick O'Beirne - SoftTest-SSTest.pdf

SOX-SprdshtRemContPITTSBURGH.pdf

wp_spreadsheetrisks.pdf

Add Spreadsheets to Your Risk Inventory - Chris Duncan 2009.doc

Top 10 Spreadsheet Compliance Risks and How to Avoid Them - Mathew Schwartz 2008.doc

ExcelRegulatoryWhitePaper.doc

SOX_Whitepaper - Panko 2006 .pdf

Why banks use spreadsheets - Dean Buckner - Financial Services Authority 2004 - D1_Buckner_EUSPRIG-2004.pdf

Solvency II - FSA extract.doc

THE APPLICATION OF COBIT TO SPREADSHEETS - ClusterSeven - Accessed 20100629 - 6_-_cobit.pdf

Waterfall or RAD.doc

reichwein_html.htm

A Comparison of Software Development Methodologies - Reed Sorensen 1995.doc

Lessons Learned From The First Scrum by Dr. Jeff Sutherland 2004.pdf

A Software Development Methodology for Research and Prototyping in Financial Markets - Kumiega and Van Vliet 2008 - 0803.0162.pdf

Quality Control in Spreadsheets - A Software Engineering-Based Approach to Spreadsheet Development - Rajalingham, Chadwick, Knight, Edwardsn 2000.pdf

Slicing Spreadsheets -An Integrated Methodology for Spreadsheet Testing and Debugging - Reichwein, Rothermel, Burnett 1999.doc

Methodology for testing spreadsheets - Rothermel, Burnett, 2005.pdf

Spreadsheet analysis and design - Ronen, Palley, Lucas - 1989.pdf

A Paradigm for Spreadsheet Engineering Methodologies - Grossman 2005.pdf

A Spreadsheet Auditing Tool Evaluated in an Industrial Context - Clermont, Hanin, Mittermeir 2002.pdf

What we know about spreadsheet errors - Panko 1998.pdf

The New Guidelines for Writing Spreadsheets - Raffensperger 2000.doc

Spreadsheet Design and Validation for the Multi-User Application for the Chemistry Laboratory Part I - Cantellops, Bonnin, Reid.pdf

Structured Methodology For Spreadsheet Modelling - Knight, Chadwick, Rajalingham.pdf


of 57

The Entity-Relationship Model-Toward a Unified View of Data - PETER PIN-SHAN CHEN 1976 - erd.pdf

Spreadsheet Professional & Sarbanes Oxley.ppt

Ensuring Spreadsheet Accuracy in the Sarbanes-Oxley Era - Clifford Coon CPA - 2005 - EnsuringSpreadsheetAccuracySOX.pdf

Getting small- a short history of the personal computer ~ Abbate 1999 ~ 00784256.pdf

NASA Significant Actions Needed to Address Long-standing Financial Management Problems - Kutz and Li 2004 - d04754t.pdf

Lotus Development Corporation’s 1-2-3 – Williams 1982 - Reprinted from Byte, issue 12 1982, pp 182-198.doc

Using the WinWin Spiral Model A Case Study - Boehm et al , IEEE Computer, July 1998 - Using_the_WinWin_Spiral_Model-A_Case_Study.pdf

Spreadsheet Guidelines_20130618_EuSpRiG

Documents

Transcript of Spreadsheet Guidelines_20130618_EuSpRiG