Background and History of SCRAM

SCRAM is the result of a collaborative effort between Adrian Pitman from the Australian Department of Defence, Angela Tuffley of RedBay Consulting in Australia, and Betsy Clark and Brad Clark of Software Metrics Inc. in the United States. 

SCRAM evolved out of their years of consulting and, specifically, their experience in performing assessments of projects in trouble. While these projects invariably experienced cost overruns, schedule slippage has consistently been the major trigger for concern and the focus of the assessments. 

The most frequently asked questions about these projects are

  • "Why do they keep slipping schedule, i.e., what are the causes of the schedule slips?" 
  • "How can we prevent schedule slippage from happening in the future?" And 
  • "Is there a reason to have any more confidence in the latest planned schedule than in the previous schedules?"
SCRAM utilizes a framework for organizing the information gathered during an assessment, for identifying the root causes of slippage, for communicating the reasons behind the schedule slippage, and for structuring recommendations to the root causes. This framework, referred to as the Root Cause Analysis of Schedule Slippage model (or RCASS) depicts the major areas impacting schedule and the relationships between these areas. RCASS is based on work by Barry Boehm[1] and by John McGarry et al.[2] and been expanded and refined as it has been used on SCRAM assessments.

Once RCASS was in place, Schedule Health Checks were added to the SCRAM method to evaluate the construction and logic of the program schedule. A Monte Carlo analysis was also added to show the probability of achieving a given planned delivery date.

In 2010, the SCRAM Process Reference / Assessment Models were developed as ISO/IEC 15504 Information technology – Process assessment conformant models in an effort to maximize consistency and provide an objective framework for assessment. This effort was undertaken to support SCRAM as it is rolled out to a wider audience of users.

Current work is directed at developing training and the SCRAM Certified Assessor Partner Program (SCAPP).

[1]  Barry Boehm, “Section 2: Risk Management Practices: The Six Basic Steps,” from Software Risk Management, IEEE Computer Society Press, 1989.

[2] John McGarry, David Card, Cheryl Jones, Beth Layman, Elizabeth Clark, Joseph Dean, and Fred Hall, “Practical Software Measurement: Objective Information for Decision Makers,” Addison-Wesley, 2001.

SCRAM is NOT an assessment of technical feasibility.

SCRAM focuses on schedule feasibility and root causes for slippage. It makes no judgment about whether or not a project is technically feasible. If there are concerns about technical feasibility, it is advisable to precede a SCRAM assessment with a technical feasibility assessment.

SCRAM is NOT an assessment of process maturity.

While SCRAM does look at processes as they relate to each of the issues areas impacting schedule, it is not an assessment of organizational / process maturity, though evidence of organizational / process maturity is certainly a factor considered in a SCRAM. Experience has shown that high maturity organizations are not immune from schedule slips so SCRAM focused on those causes of schedule slip rather than the maturity of the established processes.

Root Cause Analysis of Schedule Slippage Model