As presented last time^[1] the IT strategic ships are running aground and there seems to be no way to save them.

Decades ago Ronald Ross recognized the problems with Strategic Information Systems Planning (SISP) methodologies and voiced his concerns in a Data Base Newsletter editorial in which he recognized the failings of the then-current SISP methodologies.^[2]  Each of the SISP methodologies has its defenders, yet time has proved him to be correct in his assessment.

Ron Ross's ideas were subsequently formalized in a monograph, Resource Life Cycle Analysis:  A Business Modeling Technique for IS Planning.^[3]  There are three simple concepts in Resource Life Cycle Analysis (RLCA):

1. the resource, an enduring asset with value to the firm
2. the value chain, a linear identification of task enablement
3. the precedence, an indication of what resource enables another

As a working student who needed a project for a master's thesis, I borrowed a copy of RLCA from a co-worker, and I found the concepts intriguing as it seemed too simple to provide value.  Could a mere monograph of 90 pages really solve what others could not?  As a quant, with a degree in Decision Science, my desire is always to identify quantitative, reproducible measures, not qualitative ("I think…") results.  So my goal here was to quantitatively measure different SISP methodologies as well as to determine if any actually met, at a minimum, the most important objective of being capable of alignment with the business strategy.

I asked my company if they would be willing to permit me to perform RLCA as a thesis project.  The organization's product was intellectual property, yet IT expenditures were extremely high.  The organization not only approved the project but approved funding for several headcount for a pilot to answer the question, Is RLCA a viable SISP technique?

On the surface, RLCA seemed too simple — it seemed like a rowboat next to the juggernauts of other methodologies.  RCLA asks to:

1. identify the organization's resources,
2. identify the value chain, and
3. establish precedence.

A resource is, at a minimum, an asset that is introduced, maintained, and consumed by the enterprise.  In RLCA, the life cycle is not viewed in operational order but in enablement order — identifying what function must exist before the next function is able to occur.  How does one identify the enablement order?  Ask what task must be in place for the next task to occur.  The result is a value chain of the tasks, each task enabling the next.  Performing this enablement analysis establishes the precedence.  Precedence can occur within or between value chains.  The arrows in the RLCA are in one direction, always in precedence order.

Although the concept was simple, we found the implementation more difficult.  As IT, we tend to think in data terms; the business tends to think in process terms.  RLCA forces both types of stakeholders to think in terms of enablement of tasks, and we found that just this single activity uncovered processes that had 'paved cow paths'.  There were many process steps that were not enabling the organization so why were these being performed?

The initial pilot began with the team identifying forty-seven resource candidates for the organization.  Eventually this list was narrowed to eight resources:

1. Benefits
2. Contracts
3. Customers
4. Training
5. Employee
6. Property/Facilities/Equipment
7. Support Services
8. Work Force

Property/Facilities/Equipment and Support Services were a dilemma; these are necessary to the firm, but are the entities considered 'resources' in the RLCA sense?  The team arrived at a solution by combining these and reclassifying the combined entities as 'Infrastructure'.

The list of resources continued to be added to and subtracted from.  This exercise forced the team to think in a new way about the organization — for example, the team realized a "Competitor" is actually an organization resource.  (Think about this and see if you agree.)

Integral functions are infrastructure functions used by all resources.  The team had no agreement on how to handle integral functions and asked Ron Ross, "How do we treat functions that are required everywhere?"  Ron's reply was, "Any function common to several resources indicates the potential existence of a common resource which should be abstracted."  Another round of analysis expanded the list of resources to a final list of twelve.

1. Benefits
2. Competitors
3. Contracts
4. Customers
5. Training
6. Employee
7. Intellectual Property
8. Property/Facilities/Equipment
9. Reputation
10. Support Services
11. Vendors
12. Work Force

Each resource has a life cycle of functions:  the resource is (at a minimum) created, maintained, and terminated.  Each function is a value-added task; it enhances the previous task in some way.  We discovered maintaining granularity to be a problem — it is very easy to mix high- and low-level steps together in the same life cycle and to quickly get into the weeds rather than stay at a single level of abstraction.  The team found the optimal solution was to have the life cycles reviewed by others, iteratively, and modified as needed after each review.

Precedence is created when a resource function cannot be effective or performed until the previous function has been established or completed.  The most difficult problem in establishing precedence was the mindset of the analyst.  It's difficult to view the life cycle in enablement order rather than in operational order.  For example, identifying the number of precedence steps prior to hiring an employee was shocking and gave us a new appreciation for what it takes to create and run a company.

The team developed these rules for 'enablement':

1. The function saves money.
2. The function uses no data before it is created.
3. The function leads to rapid development of the other.
4. The function permits faster, more-convenient execution of another resource function.

Again, we sought Ron Ross's counsel, and he concurred with the enablement rules we'd identified.

When performing RLCA, a precedence architecture is developed — the as-is associations between the functions.  A team of six was able to complete the RLCA analysis of the Human Resources resource within eight weeks. 

The results?  When comparing the methodologies quantitatively, the findings were that BSP, SDP, and SMP would each take between 16 and 22 staff years to complete vs. 2.5 staff years using RLCA.  Reliability, validity, usability, and maintainability were low for BSP, low for SDP, medium for SMP, and high for RCLA.  RLCA is unlike any other SISP methodology:  no special tools or training are required; it is quicker and less expensive.  Why the dramatic differences?

• RLCA identifies resources that focus immediately on the business.
  
  
• The RLCA precedence architecture provides the ability to view the organization at its fundamental, without the peripheral processes.
  
  
• RCLA develops the enterprise data architecture.

What benefits can be gained by using RLCA?  Next time I'll wrap up with some observations about RLCA from the crow's nest.

[1]  Dagmar Cole, "The Stormy Seas of Information Strategic Planning," Business Rules Journal, Vol. 17, No. 7 (July 2016), URL:  http://www.BRCommunity.com/a2016/b864.html  

[2]  Ronald G. Ross, "My Differences with Information Engineering Over Strategic Planning," Data Base Newsletter, July/August 1992, pp. 2–10.  

[3]  Ronald G. Ross, Resource Life Cycle Analysis:  A Business Modeling Technique for IS Planning, Business Rule Solutions, LLC, ©1992.  ISBN 978-0941049016.  

# # #