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
Page 2 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

Page 3 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)

Page 4 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.

Page 5 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

Page 6 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.”

Page 7 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.

Page 8 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

Page 9 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

Page 10 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.

Page 11 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.

Page 12 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.

Page 13 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).

Page 14 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

Page 15 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.

Page 16 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)

Page 17 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.

Page 18 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
04FlowChart
11DownloadData
12LinkedData
21Calculation
31Report01
32DataFiletoGroupACs
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.

Page 19 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.

Page 20 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----------------------------------------------

Page 21 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.

Page 22 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.

Page 23 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:

Page 24 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.

Page 25 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.

Page 26 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

Page 27 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.

Page 28 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.

Page 29 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.

Page 30 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.

Page 31 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

Page 32 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!

Page 33 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.

Page 34 of 57
Component diagrams that describe how the various components of the system interact with each
other.

Page 35 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

Page 36 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.

Page 37 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].

Page 38 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
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.

Page 39 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.

Page 40 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.

Page 41 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.

Page 42 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:

Page 43 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.

Page 44 of 57
Credit Suisse
Below are extracts from an FSA action against Credit Suisse [Ref023]

Page 45 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

Page 46 of 57
VBA Documentation
Extract from : Financial modeling: using Excel and VBA By Chandan Sengupta [Ref024]

Page 47 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

Page 48 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

Page 49 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

Page 50 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.

Page 51 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"

Page 52 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

Page 53 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)

Page 54 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”.

Page 55 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&propertyT
ype=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_LJf40wTNoaDq
Ag&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBUQ6AEwAA#v=onepage&q=
excel%20%22documenting%20vba%22&f=false

Page 56 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

Page 57 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

Recommended

Recommended

More Related Content

Similar to Spreadsheet Guidelines_20130618_EuSpRiG

Similar to Spreadsheet Guidelines_20130618_EuSpRiG (20)

Spreadsheet Guidelines_20130618_EuSpRiG