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 qoto.org/@daviding (Mastodon)

    • daviding: Provocative statemen February 1, 2020
      Provocative statement by Canadian automobile reviewer. > There isn’t now and likely never will be enough electricity available worldwide to replace all the petroleum for the vehicles we currently drive.> And given that at least in Canada, only 11 per cent of fossil fuel emissions come from passenger vehicles (that’s not from some climate-change-denying website […]
    • daviding: Lecture on "Are Syst January 23, 2020
      Lecture on "Are Systems Changes Different from System + Change?" at #OCADU_SFI #SystemicDesign master's, web video and digital audio now at http://coevolving.com/blogs/index.php/archive/are-systems-changes-different-from-system-change/ . Lecture of 1h18m covered 37 of 55 slides, all online for #SystemsChange #SystemsThinking #theoryofchange
    • daviding: The 2019-2020 fires January 5, 2020
      The 2019-2020 fires in Australia are associated with a slow history of human activity. > Three hours north, in Sydney, the air quality was worse than in Jakarta. [....] > There is no doubt that the fires are growing more ferocious. Even without the changing climate, it would be inevitable; 250 years of land mismanagement […]
    • daviding: > ... a fascinating December 18, 2019
      > ... a fascinating study by Javier Miranda, principal economist at the U.S. Census Bureau; Benjamin Jones, professor at the Kellogg School of Management at Northwestern University; and Pierre Azoulay, professor at MIT’s Sloan School of Management and research associate at the National Bureau of Economic Research. They took a detailed look at the demographics […]
    • daviding: A week of deepening December 15, 2019
      A week of deepening *democratic recession* says @FareedZakaria https://www.cnn.com/2018/02/25/us/fareed-democracy-decaying-worldwide/index.html . Citing term by #LarryDiamond "Facing Up to the Democratic Recession" | Jan. 2015 | J Democracy at https://www.journalofdemocracy.org/articles/facing-up-to-the-democratic-recession/
  • RSS on IngBrief

    • Plans as resources for action (Suchman, 1988)
      Two ways of thinking about practice put (i) “plans as determinants of action”, and (ii) “plans as resources for action”. The latter has become a convention, particularly through research into Human Computer Interaction (HCI) and Computer Supported Collaborative Work (CSCW). While the more durable explanation appears the Suchman (1987) book (specifically section “8.2 Plans as […]
    • The best time to plant a tree was twenty years ago
      Does “the best time to plant a tree was twenty years ago and the second best time is now” date back further than 1988? It is time to look long and hard at the value of the urban forest and create the broad-based efforts — in research, funding and citizen participation — needed to improve […]
    • 2019/11/05 13:15 “Barriers to Data Science Adoption: Why Existing Frameworks Aren’t Working”, Workshop at CASCON-Evoke, Markham, Ontario
      Workshop led by @RohanAlexander and @prof_lyons at #CASCONxEvoke on "Barriers to Data Science Adoption: Why Existing Frameworks Aren't Working". For discussion purposes the challenges are grouped within three themes: regulatory; investment; and workforce.
    • Own opinion, but not facts
      “You are entitled to your own opinions, but not to your own facts” by #DanielPatrickMoynihan is predated on @Freakonomics by #BernardMBaruch 1950 “Every man has a right to his own opinion, but no man has a right to be wrong in his facts”. Source: “There Are Opinions, And Then There Are Facts” | Fred Shapiro […]
    • R programming is from S, influenced by APL
      History of data science tools has evolved to #rstats of the 1990s, from the S-Language at Bell Labs in the 1970s, and the
    • Bullshit, Politics, and the Democratic Power of Satire | Paul Babbitt | 2013
      Satire can be an antidote, says Prof. #PaulBabbitt @muleriders , to #bullshit (c.f. rhetoric; hypocrisy; crocodile tears; propaganda; intellectual dishonesty; politeness, etiquette and civility; commonsense and conventional wisdom; symbolic votes; platitudes and valence issues).
  • Recent Posts

  • Archives

  • RSS on daviding.com

    • 2020/02 Moments February 2020
      Winter has discouraged enjoying the outside, so more occasions for friend and family inside.
    • 2020/01 Moments January 2020
      Back to school, teaching and learning at 2 universities.
    • 2019/12 Moments December 2019
      First half of December in finishing up course assignments and preparing for exams; second half on 11-day family vacation in Mexico City.
    • 2019/11 Moments November 2019
      Wrapped up paperwork on closing out family buildings in Gravenhurst, returned to classes and technical conferences in usual pattern of learning.
    • 2019/10 Moments October 2019
      Tightly scheduled weekdays at Ryerson Chang School, weekends in Gravenhurst clearing out family building as we're leaving the town permanently.
    • 2019/09 Moments September 2019
      Full month, winding down family business in Gravenhurst, starting Ryerson Chang certificate program in Big Data, with scheduled dinners with family and friends.
  • 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