Tuesday, May 25, 2004

Management vs. Financial Accounting

It’s a commonly held misconception that my book has a heavy focus on financial accounting for software engineering. The root of this misconception is in the difference between management accounting and financial accounting. The two are not the same and for good reasons.

Financial accounting is something performed to agreed standards and principles (GAAP) designed to fairly and accurately report the true worth of a business to its owners and its true profits to the tax collector. Management accounting, on the other hand, is a mechanism for using a financial metric (dollars) as a normalizing mechanism for making decision about (often vastly) different choices and alternatives. Management accounting helps you decide whether it is better to add 900 customer account advocates in a call center in Ireland, against staffing a user experience and technical writing department in St. Louis, MO, and investing heavily in intuitive products. Management accounting helps you make decisions. It helps you to do the right thing.

Hence, my book does use management accounting as a mechanism for evaluating the merits of different aspects of the software project lifecycle and different styles of development process. The Throughput Accounting model in my book is designed to help you make decisions, for example, should you invest more in requirements, or spend more on development?

To really emphasize that management accounting has nothing to do with financial reporting, Eli Goldratt in The Haystack Syndrome, introduced a metric he called DollarDays. This is the multiplication of the value of inventory held by the number of days it has been held. Clearly, DollarDays has nothing to do with the financial worth of the inventory. It does not double in value every few days. The purpose of DollarDays is to underscore a simple lesson - holding inventory is bad practice! By using a DollarDays metric as a replacement for Investment, it makes the ROI on slow turning inventory look very bad. The purpose is simple. Amplify the valuable information and improve the signal to noise ratio from management accounting.

We could try something similar in agile development. How about StoryPointDays - multiple of the number of WIP Story Points by the number of days they have been in development - or in FDD, FeatureDays? The target would be to minimize the number. Each team in a larger organization could report its FeatureDays score each day. Management could see at a glance whether the team was making a good job of keeping batch size (Chief Programmer Work Package) small and lead time short. The lower your StoryPointDays score, the more agile you are!