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)

    • daviding: “Pre-announcing April 30 Dialogic Drinks session I'm leading …” April 23, 2024
      Pre-announcing April 30 Dialogic Drinks session I'm leading on "#Yinyang and Daojia into #SystemsThinking through Changes", online 18:30 Singapore, 11:30 London, 6:30am Toronto. Repeating May 2, 8:00pm ET. Official #EQLab notifications
    • daviding: “Diachrony (or diachronic shifts) resurrects a word from 1857…” April 10, 2024
      Diachrony (or diachronic shifts) resurrects a word from 1857, better expressing *changes through time*. A social practice publication in 1998 contrasts synchronic with diachronic.
    • daviding: “Web video introduction of 15 minutes for 1-hour Lunch and Le…” March 22, 2024
      Web video introduction of 15 minutes for 1-hour Lunch and Learn #CentreForSocialInnovationToronto on "Systems Changes Dialogues for Social Innovation" invites practitioners for upcoming monthly meetings. Evocative animated images, details deferred to conversations with mentors.
    • daviding: “Web video of slides from "From Unfreezing-Refreezing, to Sys…” March 21, 2024
      Web video of slides from "From Unfreezing-Refreezing, to Systems Changes Learning" for Dialogic Drinks of #EQLab represents only 1/5 of the time compared to peer-led discussions. Concise hosting called for brevity, and richer presentations. #SystemsThinking
    • daviding: “Hosting multiple Dialogic Drinks on "From Unfreezing-Refreez…” March 8, 2024
      Hosting multiple Dialogic Drinks on "From Unfreezing-Refreezing, to Systems Changes Learning" online, March 12 (Europe), March 14 (Americas), March 15 (Australia). #Leadership meets #SystemsThinking . Short presentations, longer discussions
  • RSS on IngBrief

    • The Nature and Application of the Daodejing | Ames and Hall (2003)
      Ames and Hall (2003) provide some tips for those studyng the DaoDeJing.
    • Diachronic, diachrony
      Finding proper words to express system(s) change(s) can be a challenge. One alternative could be diachrony. The Oxford English dictionary provides two definitions for diachronic, the first one most generally related to time. (The second is linguistic method) diachronic ADJECTIVE Oxford English Dictionary, s.v. “diachronic (adj.), sense 1,” July 2023, For completeness, prochronic relates “to […]
    • Introduction, “Systems Thinking: Selected Readings, volume 2”, edited by F. E. Emery (1981)
      The selection of readings in the “Introduction” to Systems Thinking: Selected Readings, volume 2, Penguin (1981), edited by Fred E. Emery, reflects a turn from 1969 when a general systems theory was more fully entertained, towards an urgency towards changes in the world that were present in 1981. Systems thinking was again emphasized in contrast […]
    • Introduction, “Systems Thinking: Selected Readings”, edited by F. E. Emery (1969)
      In reviewing the original introduction for Systems Thinking: Selected Readings in the 1969 Penguin paperback, there’s a few threads that I only recognize, many years later. The tables of contents (disambiguating various editions) were previously listed as 1969, 1981 Emery, System Thinking: Selected Readings. — begin paste — Introduction In the selection of papers for this […]
    • Concerns with the way systems thinking is used in evaluation | Michael C. Jackson, OBE | 2023-02-27
      In a recording of the debate between Michael Quinn Patton and Michael C. Jackson on “Systems Concepts in Evaluation”, Patton referenced four concepts published in the “Principles for effective use of systems thinking in evaluation” (2018) by the Systems in Evaluation Topical Interest Group (SETIG) of the American Evaluation Society. The four concepts are: (i) […]
    • Quality Criteria for Action Research | Herr, Anderson (2015)
      How might the quality of an action research initiative be evaluated? — begin paste — We have linked our five validity criteria (outcome, process, democratic, catalytic, and dialogic) to the goals of action research. Most traditions of action research agree on the following goals: (a) the generation of new knowledge, (b) the achievement of action-oriented […]
  • Recent Posts

  • Archives

  • RSS on

  • RSS on Media Queue

    • What to Do When It’s Too Late | David L. Hawk | 2024
      David L. Hawk (American management theorist, architect, and systems scientist) has been hosting a weekly television show broadcast on Bold Brave Tv from the New York area on Wednesdays 6pm ET, remotely from his home in Iowa. Live, callers can join…Read more ›
    • 2021/06/17 Keekok Lee | Philosophy of Chinese Medicine 2
      Following the first day lecture on Philosophy of Chinese Medicine 1 for the Global University for Sustainability, Keekok Lee continued on a second day on some topics: * Anatomy as structure; physiology as function (and process); * Process ontology, and thing ontology; * Qi ju as qi-in-concentrating mode, and qi san as qi-in-dissipsating mode; and […]
    • 2021/06/16 Keekok Lee | Philosophy of Chinese Medicine 1
      The philosophy of science underlying Classical Chinese Medicine, in this lecture by Keekok Lee, provides insights into ways in which systems change may be approached, in a process ontology in contrast to the thing ontology underlying Western BioMedicine. Read more ›
    • 2021/02/02 To Understand This Era, You Need to Think in Systems | Zeynep Tufekci with Ezra Klein | New York Times
      In conversation, @zeynep with @ezraklein reveal authentic #SystemsThinking in (i) appreciating that “science” is constructed by human collectives, (ii) the west orients towards individual outcomes rather than population levels; and (iii) there’s an over-emphasis on problems of the moment, and…Read more ›
    • 2019/04/09 Art as a discipline of inquiry | Tim Ingold (web video)
      In the question-answer period after the lecture, #TimIngold proposes art as a discipline of inquiry, rather than ethnography. This refers to his thinking On Human Correspondence. — begin paste — [75m26s question] I am curious to know what art, or…Read more ›
    • 2019/10/16 | “Bubbles, Golden Ages, and Tech Revolutions” | Carlota Perez
      How might our society show value for the long term, over the short term? Could we think about taxation over time, asks @carlotaprzperez in an interview: 92% for 1 day; 80% within 1 month; 50%-60% tax for 1 year; zero tax for 10 years.Read more ›
  • 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