Coevolving Innovations

… in Business Organizations and Information Technologies

Services methods in a process framework

From the mid-1990s to the mid-2000s, methods for organizing for service engagements at scale were developed at IBM. Although this investment in knowledge management was huge, changes in the organization by the late-2000s saw this rich body of intellectual capital practically disappear.  Appreciation for the framework remains in the memories of practitioners in the IBM Global Services organization — particularly the methodologists — immersed during that period. Some foundational historical artifacts can be rediscovered on the open Internet:

  • 1. Configurable Development Processes (2002)
  • 2. Method Adoption Workshops (2000)
  • 3. Eclipse Process Framework Composer (2007)

The resemblance to pattern language, as prescribed by Christoper Alexander, is not accidental. Excerpts from these three sources are provided here, to entice readers who might seek out the full articles.

1. Configurable Development Processes (2002)

The Work Product based methods started in IBM at the rise of object-oriented methods. With OO as a new paradigm, incompatibilities across the variety of approaches frustrated clients trying to get work done.  The end results seemed pretty much the same. The resolution for IBM came through centering on ends (work products) first, and means (techniques) second. The methods originating in software development became cross-appropriated into services engagement for other domain offerings (e.g. business strategy, organizational change).

Here’s an excerpt that shows the centrality of Work Product Descriptions (WPDs) from:

Work products cover the full range of project work including project management, business process design, organizational change, requirements, usability, architecture, design, construction, and testing. Figure 1, for example, shows work products associated with the application development part of the framework.  [p. 72]

Figure 1. List of 96 WPDs used in IBM custom application development (v1.1) [p. 74, numbering added]

  1. Acceptance Test Plan
  2. Analysis Class Descriptions
  3. Analysis Class Diagram
  4. Analysis Guidelines
  5. Analysis Interaction Diagram
  6. Analysis State Chart Diagram
  7. Application Program Interface
  8. Architectural Decisions
  9. Architectural Template
  10. Architectural Overview Diagram
  11. As-Is Organization Assessment
  12. As-Is Organization Description
  13. As-Is Process Definition and Assessment
  14. Build procedures
  15. Business Context Diagram
  16. Business Event List
  17. Business Object Model
  18. Business Process Model Deployment Plan
  19. Business Rule Catalog
  20. Candidate Asset List
  21. Change Cases
  22. Classified Business Terms
  23. Coding Guidelines
  24. Component Model
  25. Configuration Management Procedures
  26. Cost-Benefit Impact Analysis
  27. Current IT infrastructure
  28. Current Solution Evaluation
  29. Customer View and Requirements
  30. Decision Framework
  31. Deployment Unit
  32. Deployment Unit Matrices
  33. Design Class Descriptions
  34. Design Class Diagram
  35. Design Guidelines
  36. Design Interaction Diagram
  37. Design State Chart Diagram
  38. Early Usabiity Evaluation
  39. Education and Training Pan
  40. End User Training Materials
  41. End user Training Specifications
  42. Envisioned To-Be Business Goals
  43. Executables
  44. Glossary
  45. Increment Goals
  46. Information Technology Standards
  47. IT Organization Skills Gap Analysis
  48. IT Readiness Assessment and Issues
  49. Logical Data Model
  50. Nonfunctional Requirements
  51. Object/Action Table
  52. Operational Model
  53. Organization Change Readiness Assessment and Issues
  54. Package Technical Criteria
  55. Physical Database Design
  56. Physical Packaging
  57. Process Model (data flow diagrams)
  58. Process/Data Usage Matrix
  59. Program Module Invocation Model
  60. Program Module Specification
  61. Project Estimates
  62. Project Goals
  63. Project Tracking Reestimates
  64. Project Workbook Outline
  65. Reference Architecture Fit/Gap Analysis
  66. Release Plan
  67. Request for Information
  68. Request for Vendor Proposal and Response
  69. Service Level Characteristics Analysis
  70. Software Distribution Plan
  71. Source Code
  72. System Context Diagram
  73. System Management Plan
  74. System Test Plan
  75. Technical Prototype
  76. Test Cases
  77. Test Results
  78. Training and User Support Approach
  79. Transaction Descriptions
  80. Usability Design and Evaluation Plan
  81. Usability Requirements
  82. Usability Test Plan
  83. Usability Test Report
  84. Use Case Mode
  85. Use Case Validation Report
  86. User Interface Architecture
  87. User Interface Conceptual Model
  88. User Interface Design Guidelines
  89. User Interface Design Specification
  90. User Interface Prototype
  91. User Profiles
  92. User Support Materials
  93. Vendor Qualifications
  94. Viability Assessment
  95. Visual Resources

The process guidance was closely related to other intellectual capital that had emerged from IBM.

The dynamic stability model [4] provides a management consultant’s perspective on this approach to configuration. This model classifies industrial production processes into invention (meaning each product is uniquely designed and built), mass production, continuous improvement, and mass customization. To achieve the generally desirable goal of mass customization, in which product and process are both customized to the customer’s needs, it is necessary to have modular processes and a means of configuring them. Similarly, the sense-and-respond model of business organization [1], whose goal is responsive, adaptive enterprises, also relies on modular descriptions of capabilities.  [p. 72]

This 2002 article had the benefit of hindsight, from real customer engagements.

Experience at IBM

The work product approach was first developed and used at IBM by the Object-Oriented Technology Center, a group since disbanded, but whose mission from 1994–96 was to support internal OO projects. One of the main reasons for their emphasis on WPDs was the difficulty they found in reaching consensus on the process aspects of development. They found it easier to agree on the artifacts that have to be produced; their work is described in [3].

Since 1996 a number of other IBM working groups have adopted the approach. The scope has been substantially extended, for example to cover project management, various consulting methodologies, and a wide range of specialist technical disciplines. Over 300 WPDs are in use, most of them shared by many groups. The approach has been standard in most of IBM Global Services since September 2000. [p. 72]

It’s unlikely that any single consultant would every execute on more their domain subset of the 300 WPDs, but clients with long relationships would be interested in how deliverables from IBM would hang together.  For consultants, WPDs provided guidance towards produce higher level of quality, uniformly.

Work Product Descriptions

A WPD is very simply a 3–10-page description of a project artifact that uses the following headings:

  1. Description
  2. Purpose
  3. Impact of Not Having the Work Product
  4. Reasons for Not Choosing the Work Product
  5. Notation
  6. Example
  7. Development Approach
  8. Validation and Verification
  9. Estimating Considerations
  10. Advice and Guidance
  11. References

A WPD may take a variety of forms, from a simple document to a set of linked HTML pages. The accompanying sidebar shows extracts from a WPD for a user interface prototype. Dependency diagrams (see Figure 2) are an overview of the work products in a given area. A work product B ‘depends on’ work product A if a change to A should lead to a check on the consequences for B. For example, a design work product may depend on one or more requirements work products. [p. 73, numbering added]

Dependency diagram showing work product descriptions
Figure 2. Fragment of dependence diagrams showing work product descriptions associated with usability [p. 75]

The focus on Work Products surfaces the other necessary parts to be used in engagements.

The Rest of the Process Framework

The process framework scheme used by IBM has four main components:

  • Work Product Descriptions, classified by subject matter, with associated dependency diagrams, as described here.
  • Work Breakdown Structures (WBS) describe the temporal structure of a project. A WBS is a skeleton plan, which divides the project into a hierarchical structure of major and minor checkpoints each with exit criteria and a description of the work needed to reach the checkpoint.
  • Roles describe sets of skills. They are associated with WPDs and with elements in the WBS.
  • Techniques are used for detailed guidance on building a work product or group of work products, when the terse summary in the Development Approach section of the WPD is not sufficient. They can differentiate the use of the same WPD in different contexts.

Within IBM the term “engagement model” is used for all the material needed to describe a certain class of project. An engagement model consists of a set of WPDs, a WBS, a set of role descriptions, and a set of techniques. The management of the process framework is quite complicated. Engagement models and a few of the specialist elements they contain are managed by the groups that do the projects they describe. Other groups manage the WPDs, roles, and other reusable components. [p. 74]

In 2006, I left the IBM Global Services organization to join the Industry Solution Sales team. By that point, the work product based methods had mostly disappeared.

2. Method Adoption Workshops (2000)

Every services engagement with a client is unique. Project teams would combine IBM Global Services practitioners (as temporary change agents) and client staff (as the more permanent staff responsibility for ongoing operations and maintenance).   In chartering a scope of work, a Method Adoption Workshop would select from the Work Product Descriptions (WPDs) as a specification of the artifacts to be completed.

In the early 2000s, IBM services professionals numbered in the tens of thousands (10,000s).  In web searches, I discovered a colleague (whom I’ve never met!) who has documented Method Adoption Workshops.

The MAW is the keystone of method deployment, and requires preparation, education, leadership and follow-on mentoring. The MAW is undertaken during solution design to position the proposal and Statement Of Work utilizing the method.

A MAW helps in determining e.g. a tailored method, key requirements, work product list, resourcing list, PID, risk assessment, templates and outputs. The workshop essentially acts as a discussion venue to determine the optimal activities for the project. Various methods can be used for these workshops. Most of them prescribe how to collect and specify requirements and in some cases how to manage them also. These workshops also help in putting in place effective project change management processes. MAW is used to tailor and adopt the project management and technical methods for the product or service and determine the optimal activities needed. Post MAW, stakeholders are identified and various elicitation techniques are used for determining the requirements. Techniques can vary according to the group of stakeholders.

In addition to this description, a copy of the original technique paper (e.g. how-to guide) is linked.

Technique Paper: Conducting a Method Adoption Workshop

The technique paper following the format standard in the method guidance:

  1. Introduction
  2. Description
  3. Purpose
  4. Objectives and Results
  5. Participants
  6. Key Roles and Responsibilities
    1. Method Exponent
    2. Principal
    3. Project Manager
  7. Tools Environment
    • Engagement Support Environment (ESE)
  8. Agenda
  9. Preparing for the Method Adoption Workshop
  10. Conducting the Method Adoption Workshop
    1. Basic Tailoring Procedure
    2. Results of the Method Adoption Workshop
  11. Advice and Guidance

Method Adoption Workshops were typically conducted by Method Exponents. Knowing all of the potential relevant work products, work breakdown structures, roles and techniques required a deep appreciation of the content, to be applied in the specific context.  In the vocabulary of the dynamic stability model, small-scale engagements might be managed in a style of invention (i.e. dynamic process change + dynamic product change), whereas large-scale engagement in a style of mass customization (i.e. stable process change + dynamic product change) require greater process guidance.

3. Eclipse Process Framework Composer (2007)

The Engagement Support environment in the late 1990s and early 2000s was based on collaborating in Lotus Notes.  Lightweight support is sufficient for organizational consulting.  In the late 2000s, large software engineering projects might instead apply the Rational Method Composer product,  as an engagement tool consistent with the delivery of services engagements in the mass customization style.

Throughout the 2000s, IBM was a primary contributor to the Eclipse Foundation.  Thus, the Eclipse Process Framework Composer was an open source version of the commercial IBM product offering.  There are two documents that describe the approach:

The first document outlines the vision, of (i) method content, and (ii) engagement/product processes, coming together in a cohesive way, in the mass customization style.

The EPF Approach
Figure 1: The EPF Approach of managing libraries of reusable method content that can be used to assemble processes. Reusable method content and processes can be configured by EPF Composer users for specific project needs and then published for enactment as project plans or process documentation.  [Haumer, 2007a]
In the second article, the incorporation of the Work Product style into tools is clear, in an example task.

Use Case Analysis in EPF Composer
Figure 10: The method of performing Use Case Analysis represented as a task in EPF Composer. The example shows how a task is rendered into HTML and presented to a user. Detailed step descriptions are provided in collapsible sections. All blue text in this figure represents hyperlinks to pages of the related method content elements.  [Haumer, 2007b]
The decoupling of (i) method content from (ii) process is at the foundation of the Method Authoring.

Method Content, Process
Figure 14: Applying method content in a process. The figure shows how method content defined with tasks, roles and work products is sequenced in processes.  [Haumer, 2007b]
So, if such tools and methods are sufficiently well developed — and readily accessible to all as open source tools — then, why have they not been more fully adopted?  The answer would be in context for the business, as described in:

The foundational question may be:  do we treat projects (e.g. services engagements) as (i) invention; (ii) mass production; (iii) continuous improvement; or (iv) mass customization?

Really new product and process development seeks breakthroughs, in a mode of invention.  Beyond the first-of-a-kind, most organizations want to scale, and that generally means mass production.  There’s no direct path from mass production to mass customization, though.

We have observed that it is not just possible to reapply processes used in mass production and simply transfer them to conditions of mass customization and continuous improvement. Processes created for conditions of mass production are designed and managed with efficiency and low cost in mind. They simply do not have the inherent flexibility to operate in a networked organization. Thus the path to dynamic stability requires that the organization undergo a significant process development or redevelopment effort aimed specifically at building process or knowledge capabilities. Any attempt to move to dynamic stability from the old competitive strategies without significant process transformation does not work. [p. 59]

Making the transformation:  The wrong path
Figure 9. Making the transformation: The wrong path [Boynton, Victor, Pine 1993, p. 59]

Understanding that transformation to mass customization must follow a carefully thought-out right path is a critical step to success for firms in attempting to position themselves on the new competitive strategies. [….] The firms themselves did not try to leapfrog existing capabilities without thinking through organizational design issues and consequent information challenges required for dynamic stability. In each case, careful engineering or re-engineering of process capabilities positioned the firms and their manages to meet the dual competitive challenges of product differentiation and low cost made possible by mass customization. [p. 61]

Making the Transformation: The right path
Figure 10. Making the Transformation: The right path [Boynton, Victor, Pine 1993, p. 60]
Given that agile development has now become the prevailing frame for projects these days, what does this say about the legacy of intellectual capital described above?  More lightweight methods were proscribed with the scope of engagement types, e.g. the Open Unified Process.  How were such variations developed?  This takes us beyond a single method, and towards a true discussion of methodology.  Methods and tools coevolved in the larger Eclipse Process Framework project.  For methodologists (or method exponents), ways for getting started remain openly accessible on the web.

Leave a Reply

Your email address will not be published. Required fields are marked *

  • RSS (Mastodon)

  • RSS on IngBrief

  • Recent Posts

  • Archives

  • RSS on

  • RSS on Media Queue

  • Meta

  • Creative Commons License
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
    Theme modified from DevDmBootstrap4 by Danny Machal