RAID

Aside from dealing with organizations that oftentimes must use Excel as workarounds due to limitations of legacy software systems, I was reminded of the ubiquity of Excel in a recent article by my colleague Dave Gordon at AITS on the use and misuse of RAID (Risk Assumptions, Issues, and Decisions).  His overall assessment of the weakness of how RAID can be applied is quite valid.  But the literature on risk is quite extensive.  The article “Risk Management Is How Adults Manage Projects” at Glen Alleman’s Herding Cats blog is just one quick overview of a very mature process that has a large amount of academic, statistical, mathematical, and methodological grounding.

The dangers that Dave is identifying are not implicit in RAID so much as they are implicit in anyone who uses Excel.  It is not that Excel is a bad tool.  It is very useful for one-off spreadsheet problems.  It is not a software solution and is not meant to be one.  Going to Microsoft’s site on the progression of Excel to Access to SQL Server clarifies the differences.

Note that in my title I didn’t use the word tool.  This word has been the source of great confusion.  To the layman it seems to be a common-sense descriptive.  When you physically work on something–a home repair, an automobile, a small bit of machinery–you have a toolbox and you have a set of tools to address the problem.  So the analogy is that projects (and other processes) should be approached the same way.  Oftentimes this is done in the shorthand of marketing.  It’s easier to explain something complex through a simple analogy.

But no descriptive has been more harmful or destructive in preventing people from fully conceiving of an understanding of the needed solutions in the project management community than the word tool when applied to software applications.  A project is a complex system–a complex adaptive system.  What is called for are software applications that fit into the manner that project systems operate.

Back in the 1980s and 1990s there was a great deal of justification to take the spreadsheet software that came with the operating environment or the Office Suite and adapt it administrative needs.  There were a great number of individual tasks and processes that needed to be automated, and the market had not yet responded to that demand.  In some cases the demand was only vaguely understood, and the solutions were not fully conceptualized.

Then, as software applications became more sophisticated to begin to replace manual processes, they oftentimes could not address all of the corollary operations that need to be performed in those systems.  Oftentimes, the solutions addressed the 80% need of these requirements, and so one-off workarounds until the software was developed to be more comprehensive, were applied.  The very process of automating previously manual tasks had an effect on organizational processes, driving them toward greater sophistication.  The phenomena of Knowledge Discovery in Databases (KDD) is but one of these effects.

But note that when relying on Excel for important processes, such as risk handling, that KDD is impossible.  An accountant or head of finance in a corporation would not use Excel to keep the company’s books, even though that was the original target audience back in the 1980s for spreadsheet software.  No doubt that financial personnel use Excel to supplement their work, but using it as the primary solution to constitute the system of record would be foolhardy.  Even very small businesses today use more sophisticated financial management solutions.

The reason why one must be extra careful with any process when using Excel as the solution is that the person is still to a large extent, a part of the computer.  The person must perform operations that a spreadsheet application cannot perform.  This is why in risk management that assumptions, issues, decisions, and handling are tied to the work.  The origin of all work decomposed from the requirements are the plan and then the detailed schedule.  The detailed schedule, consisting of activities, is then further decomposed into the work organization: tasks, resources, etc.  There may or may not be a WBS or OBS that ties performance reflected in terms of earned value.

Using Excel as an external tool in addressing this important and essential process separates it from the other elements of project management systems.  It thus creates a single point of failure in the process–the mind of the individual keeping the Excel spreadsheet.  It also containerizes the information, preventing it from being mainstreamed into the larger organization, and thus being a source of KDD.