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:

• Cameron, John. 2002. “Configurable Development Processes.” Communications of the ACM 45 (3): 72–77. https://doi.org/10.1145/504729.504731.

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]

• [4] Pine, B.J., Victor, B., and Boynton, A.C. Making mass customization work. Harvard Business Review (Sept.–Oct. 1993), 108–119.
• [1] Haeckel, S.H. Adaptive Enterprise: Creating and Leading Sense-and-Respond Organizations. Harvard Business School Publishing, June 1999.

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].

• [3] Livesey, D., and Guinane, T. Developing Object-Oriented Software: An Experience-Based Approach. Prentice Hall, 1997.

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]

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.

• Thijs van Eembergen, “The Method Adoption Workshop” | August 15, 2015 at https://itroommigration.nl/2015/08/31/the-method-adoption-workshop/

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.

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:

• Eclipse Process Framework Composer, Part 1:  Key Concepts | Peter Haumer | 2007 at https://www.eclipse.org/epf/general/EPFComposerOverviewPart1.pdf; and
• Eclipse Process Framework Composer: Part 2:  Authoring method content and processes | Paul Haumer | 2007 at https://www.eclipse.org/epf/general/EPFComposerOverviewPart2.pdf

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.

In the second article, the incorporation of the Work Product style into tools is clear, in an example task.

The decoupling of (i) method content from (ii) process is at the foundation of the Method Authoring.

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:

• Boynton, Andrew C., Bart Victor, and B. Joseph Pine. 1993. “New Competitive Strategies: Challenges to Organizations and Information Technology.” IBM Systems Journal 32 (1): 40–64. https://doi.org/10.1147/sj.321.0040. Alternate search at https://scholar.google.com/scholar?cluster=17721219986364944726

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]

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]

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.