Toward Enterprise Agile

Scalability
A New Way to Look At Accounting
for Agile Software Development Costs

Pat Reed
August, 2008
 Agenda
  Welcome & Session Objectives
  Background and SOP 98-1 Guidelines
  Problem Statement
  Refresher on Agile and Waterfall Comparison
  Brainstorm
  Success Metrics
  Idea Generation Activity and Discussion

  Testing our Ideas

  Ladder of Inference

  Walkthrough Recommended Solution

  Detailed Walkthrough by Stage
  Review of Key Learnings & Retrospective
  Discussion and Q & A
  Frequently Asked Questions & Appendices
 Session Objectives
  Increase our understanding of how we
solve problems
  Increase our understanding of the FASB
accounting standards
  Solve a problem on how to apply SOP
98-1 guidelines to Agile projects
  Recommend an Agile Accounting
Standard
 Background
  Historical absence of standard accounting methodologies
  Explosive and strategic growth of technology in the 90’s
  Recognition that internal software investments have significant
future benefits and should be capitalized accordingly
  Mandatory accounting guidelines require all organizations to
better define, standardize and report internal IT development
costs
  Guidelines were designed around a phased, waterfall based IT
investment model where IT projects are delivered in discrete,
time boxed phases
  As organizations adopt Agile development and delivery models,
they may encounter inherent constraints and points of friction
with legacy accounting practices and policies
  Before Agile can scale as the primary mode of developing
software, this accounting issue needs more clarification and an
Agile software and project accounting practice needs to be
developed.
What Areguidelines
Mandatory
  the Key SOP
published 98-1
in 1998 Guidelines?
prescribing how all organizations
must capitalize or expense internal IT projects based on project stage and
type of work.
  Identifies three stages of an IT project and whether the costs incurred in
each should be classified as expense or capital. In general:
  Preliminary Stage – Costs must be expensed

  Application Development Stage – Most costs should be capitalized

  Post Implementation Stage – Costs must be expensed

  Capitalization begins when (a) the preliminary project stage is completed

and (b) management, with the relevant authority, implicitly or explicitly
authorized and commits to funding a computer software project and it is
probable that the project will be completed and the software will be used to
perform the function intended.
  Capitalization ends no later than the point at which a computer software
project is substantially complete and ready for its intended use.
 What’s The Problem?
  To ensure compliance, IT managers must now estimate, allocate, track and
report labor costs to internal IT projects based on project work done in three
specific phases: Preliminary, Development and Post Implementation
  Organizations utilizing a traditional waterfall model can readily adapt their
labor and project costing to the guidelines using the following framework:

Preliminary - - - - - - - - Development - - - - - - - - - - - - - Post Implementation - -

 Waterfall Methodology

Effort


Time





3

months

 3 months
Iteration
1





2







3




4




5




6


Time

Agile Methodology

Effort

 Agile Development Roadmap
Project Release Plan
Scheduled Scheduled Scheduled
release release release

Scheduled Scheduled
milestone milestone

Analysis Analysis Analysis Analysis Analysis Analysis Analysis Analysis Analysis Analysis Analysis Analysis
Design Design Design Design Design Design Design Design Design Design Design Design
Dev. Dev. Dev. Dev. Dev. Dev. Dev. Dev. Dev. Dev. Dev. Dev.
QA QA QA QA QA QA QA QA QA QA QA QA

Release N Release N+1 Release N+2

Iteration Iteration
© ThoughtWorks, 2006

How can organizations who have adopted an Agile or iterative

development model ensure compliance and accurately estimate,
allocate and track labor costs to IT projects based on project work done
in three specific phases when analysis, design, development and QA
work is continuously repeated and intertwined throughout each iteration?
Brainstorm
 Success Metrics
  Define a Standard Accounting Practice for Agile Project
Costing that is:
  Defensible (effectively addresses the guidelines)
  Auditable
  Scalable (all projects, programs, portfolio, enterprise)
  Agile in nature:
  Easy to implement (light touch)
  Easy to interpret (clear bright lines and simple rules)
  Easy to administer (open informaiton)
  Reduces waste (people above processes)
  Efficient (value focus)
  Reduce the risk of over-expensing project costs
  Reduce the risk of audit findings
Ideas . . .
Activity
Discussion
Activity
 Possible Solutions….
Most organizations fall into the trap of over-
engineering a solution and ask every team
member to meticulously track every hour
spent on analysis vs. design vs.
development work throughout each day and
iteration

This approach adds significant waste and

provides neither an auditable or sustainable
solution.

Other Ideas?
Source: http://www.systems-thinking.org/loi/loi.htm
 Ladder of Inference

  Reflection
  Inquiry
  Learn to work the
ladder vs. leaping up
the ladder
  Know when to climb
down vs. up

Metaphor for our Thinking Process

Source: http://www.actiondesign.com/resources/concepts/ladder_intro.htm
 “Working” the Ladder

take actions based on

beliefs
adopt beliefs

draw conclusions

make assumptions

add meanings

select “data”
Observable “Data”
& experiences
  We are so skilled at thinking that we jump up
the ladder without knowing it
  Selective Perception
  Unaware of our Paradigms
  Bottomline: our conclusions feel so obvious to us that
we see no need to retrace the steps we took from the
data we selected to the conclusions we reached
  The contexts we are in, our assumptions, and
our values channel how we jump up the
ladder
  Mental models reinforce patterns of selective
perception
  So let’s step back one or two rungs on our
ladders of inference and explore another
approach
 Recommended Approach . . .
Step 1: Paradigm shift: let’s suspend our knowledge of the
differences between Agile and Waterfall…..and take a new
look at the “waterfall centric” project stage framework
through an Agile lens
Step 2: Adopt an Agile Project Stage Framework
Step 3: Standardize on a lightweight process to capture
evidence of management authorization and commitment
to project funding
Step 4: Apply and adapt this framework to your organization
 Agile Project Stages
  The Preliminary Project Stage is analogous to research and
development activities, primarily expense and covers the conceptual
formulation and evaluation of alternatives, determination of existence
of needed technology and final selection of alternatives (The What).
  The Development Stage covers all work related to The How: design
of software, configuration and interfaces, coding, retrospectives,
installation to hardware, testing (including parallel processing) and all
work preparing the software for its intended use.
  Standardize on a clear bright line between the preliminary (what) and
the development (how) phases, and capture evidence of management
approval (which marks the start of capitalizable work): Design
Storming
  Standardize on an equally clear bright line that marks the end of
development which concludes when all iterations of the project are
complete and the asset is ready for its intended use and placed in
service (which includes all deployment work necessary to get the
software into production as well as production testing, acceptance and
stabilization): 72 hours after production implementation and final user
acceptance testing.
 Expense vs. Capital
Expense
Inception:
Customer Evaluations
Quickstart
Inception Deck
Treatment

Design Storming
• Feature 1
Release N: Theme • Feature 2
• Feature 3
R
Release

Backlog Iteration 1 Iteration 2 Iteration 3 Iteration … Backlog

• Story 1 • Story 1 • Story 3 • Story 5 • Story 8 • Story 11
• Story 2 • Story 2 • Story 4 • Story 6 • Story 9 • Story 12
• Story 3 • Story 7 • Story 10 • Story …
• Story …

Capital
Walkthrough by Stage
 Preliminary Project Costs…
  Strategic decisions to allocate resources
between alternative projects
  Determining performance requirements (what do
we need the software to do) and high level
systems requirements
  Vendor product demonstrations
  Exploring alternatives (Buy vs. Build)
  Feasibility Analysis
  Vendor selection
Stage 1: Project Inception

High
Level
Estimated
Backlog

Customer Customer Customer Customer

Evaluation Evaluation Evaluation Evaluation

© ThoughtWorks, 2006
 Clear Bright Line
  Critical Success Factor: It’s important to
capture evidence of management
authorization (with time and date stamps) to
document transition from expense
(preliminary phase) to capital (development
phase) of the project
  This clearly marks the transition from the
“What” to the “How”
  Memorializing and documenting this
authorization is critical for future auditability
 Stage 2: Development
  Most costs should be capitalized:
  Designing the chosen path, including software configuration and
software interfaces
  Refinement of requirements (i.e. creation of detailed Use Cases
or Stories, which have a lifecycle and evolve as they transform
and mature)
  Internal and external labor costs and fees associated with
development (design, build, test, implement)
  Costs to develop or obtain software that allows for access or
conversion of old data by new systems
  Costs that Should be Expensed Include:
  Training and Data Conversion (except as noted above)
 Stage 3: Post Implementation
  Another clear bright line: 72 hours after
implementation and production acceptance
  Post Implementation (Expense) examples include:
  Support turnover and training
  Certifying operational system
  Post implementation review
  Collecting and analyze process data
  Ongoing Maintenance
  Transformation / process reengineering / workforce restructuring
 Key Learnings
  Applied some Systems Thinking Concepts to
our mental models, defined our success
metrics (and used them to test ideas);
explored some ideas on how to solve a sticky
accounting problem, gained a better
understanding of SOP 98-1 guidelines and
proposed a standard accounting practice
consistent with Agile principles
  How to “work” the ladder of inference to slow
down our thinking processes enough to
reflect, look, listen and explore alternatives
 Retrospective
1.  What are your observations and thoughts about
today’s session?
2.  What new information was the most impactful for you
3.  What puzzles you about the information presented
today?
4.  What obstacles do you see that could impact your
use of the materials we covered today?
5.  What ideas and recommendations do you have to
share?
Discussion

Q&A
Appendices

FAQ’s
And
Reference
Frequently Asked Questions
  What does Capitalization mean?
  When costs are capitalized they are recognized as
assets on the balance sheet instead of expenses on
the income statement. These costs are depreciated
or expensed periodically over the useful life of the
asset which helps short term profit.
  What is Useful Life?
  Entities will decide useful lives for amortization purposes.
The SOP cautions that internal-use software often has a
relatively short useful life, typically 3 to 5 years.
 FAQ’s
  What are the Accounting Regulations?
  All Corporations (private and public) are required to
follow US Generally Accepted Accounting Principles
(GAAP)
  Statement of Position 98-1 (SOP 98-1) is the GAAP
pronouncement that governs accounting for software
developed for internal use (not marketed to others)
  Why is GAAP Important?
  GAAP provides for standardized financial reporting
which helps investors make informed decisions about
each company (and eliminates inconsistencies in
practice across organizations)
 FAQ’s
  What Happens if Corporations Don’t Follow GAAP?
  IT management is required to disclose the irregularity to
investors
  The outside auditors could determine that financial
statements are not fairly stated which would adversely
impact financial statement rating
  Organizations could be required to reclassify capital
expenditures as expense
  Who is responsible for compliance with SOP 98-1 and
related Software Capitalization Policies?
  IT Finance and Portfolio Management are responsible for
monitoring compliance
  PM’s are responsible for understanding and adhering to
SOP 98-1
  IT management is responsible for ensuring compliance
with SOP 98-1
 FAQ’s
Expense vs. Capitalize
  Development Concept   Detailed Analysis (post Design
Storming)
  Business Process Reengineering
  Design Requirements
  Feasibility Analysis
  Physical & Logical Design
  Evaluation of System
  Make, Buy or Reuse Decisions
  Selection of System
  Purchased Software
  High level requirements
  Coding / Development
  Project Management
  Iteration Management
  Overhead Costs
  Retrospectives
  Administrative Support
  Integration & Installation
  User Training
  Conversion Software
  Data Conversion
  Testing
  Maintenance
  Stabilization
  Bug Fixes
  Major Functional Enhancements &
Upgrades
  Hardware
 FAQ’s
  What
about PM’s and Management?
Can we capitalize those costs?
  General and administrative costs and overhead
costs should not be capitalized. They must be
expensed as incurred regardless of the project
stage to which they belong.
  If a PM or manager is developing the software
(e.g. creating code, making development
decisions) those costs can be capitalized. If they
are providing general oversight, guidance and
planning, their costs must be expensed.
 FAQ’s
  What
about Business Process
Reengineering and IT Transformation?
  Costs should be expensed as incurred
  Preparation of RFPs
  Current state assessment: The process of
documenting the entity’s current business process,
except as it relates to current software structure.
  Process reengineering: The effort to reengineer the
entity’s business process to increase efficiency and
effectiveness
  Restructuring the workforce: The effort to determine
what employee makeup is necessary to operate the
reengineered business process
 FAQ’s
  What about Upgrades and Enhancements?
  Can be capitalized if they meet the following requirements:
  Modification results in additional functionality
  The costs are a minimum of $25,000 per project, or the costs
are a minimum of $2,500 per individual item
  Generally, IT Finance and Portfolio Management are
responsible for determining whether all or part of the
upgrades/enhancements can be capitalized. Often, one
part can be capitalized and another must be expensed.
  Labor associated with control enhancements and bug fixes
are not considered as upgrades/enhancements and should
be expensed as incurred
 Useful References
  Link to SOP 98-1 document: http://
efile.mpsc.cis.state.mi.us/efile/docs/
14201/0031.pdf
  MindTools: http://www.mindtools.com/pages/
article/newTMC_91.htm
  FASB - Financial Accounting Standards
Board: http://www.fasb.org/st/
 Accounting Glossary
  AcSEC – AICPA’s Accounting Standards Executive Committee
  SEC – Security and Exchange Committee
  EITF – SEC’s Emerging Issues Task Force
  GAAP – Generally Accepted Accounting Principles from the
American Institute of Certified Public Accountants (AICPA)
  SOP 98-1 – American Institute of Certified Public Accountant’s
Statement of Position Accounting for the cost of Computer
Software Developed or Obtained for Internal Use – issued on
2/27/1998 which all non governmental public or private
organizations must follow and which are now part of GAAP. SOP
98-1 standardizes how organizations measure and report their
investments
 Agile Glossary
  Quickstart – High level Analysis and Requirements Capture
  Customer Evaluations
  Identify customer preferences
  Eliminate bad ideas

  Inception Deck
  Charter: Organizational and Departmental Objectives
  Business & Technical Outcome Vision (“What” & “How”)
  In Scope / Out of Scope and Context Diagram
  High Level Risks and Project Approach and Estimates
  Stakeholder Agreements
  Release Plan and Staffing Plan
  Project Organization and Management Structure
  Trade Off Sliders

  Treatment
  Solution Description and Metrics of Success
  High level functionality matrix and impact analysis
  Assumptions and Questions
  Estimated durations / costs / budget / contingency
  High level resource plan
 Agile Task Codes
01 – Hardware
Assets
{
02 – System Software
03 – Application Software
CAPITAL

Quickstart 04 – Analysis in Preliminary Project Phase EXPENSE

Iteration 05 – Design Storming & Application Software Design CAPITAL

Project 06 – Application Software Construction
Lifecycle 07 – Testing through Production / user acceptance

08 – Change Mgmt/Process Reengineering

Related
09 – Data Conversion
Project EXPENSE
10 – Training
Expense
12 – Post Implementation
13 – Application Software Maintenance
15 – Leased Equipment
16 – Other Expense
17 – Hardware & System Software Maintenance
Overcoming An Accounting
Obstacle to
Enterprise Agility

[email protected]
415 427-5431