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.
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]
- Acceptance Test Plan
- Analysis Class Descriptions
- Analysis Class Diagram
- Analysis Guidelines
- Analysis Interaction Diagram
- Analysis State Chart Diagram
- Application Program Interface
- Architectural Decisions
- Architectural Template
- Architectural Overview Diagram
- As-Is Organization Assessment
- As-Is Organization Description
- As-Is Process Definition and Assessment
- Build procedures
- Business Context Diagram
- Business Event List
- Business Object Model
- Business Process Model Deployment Plan
- Business Rule Catalog
- Candidate Asset List
- Change Cases
- Classified Business Terms
- Coding Guidelines
- Component Model
- Configuration Management Procedures
- Cost-Benefit Impact Analysis
- Current IT infrastructure
- Current Solution Evaluation
- Customer View and Requirements
- Decision Framework
- Deployment Unit
- Deployment Unit Matrices
- Design Class Descriptions
- Design Class Diagram
- Design Guidelines
- Design Interaction Diagram
- Design State Chart Diagram
- Early Usabiity Evaluation
- Education and Training Pan
- End User Training Materials
- End user Training Specifications
- Envisioned To-Be Business Goals
- Increment Goals
- Information Technology Standards
- IT Organization Skills Gap Analysis
- IT Readiness Assessment and Issues
- Logical Data Model
- Nonfunctional Requirements
- Object/Action Table
- Operational Model
- Organization Change Readiness Assessment and Issues
- Package Technical Criteria
- Physical Database Design
- Physical Packaging
- Process Model (data flow diagrams)
- Process/Data Usage Matrix
- Program Module Invocation Model
- Program Module Specification
- Project Estimates
- Project Goals
- Project Tracking Reestimates
- Project Workbook Outline
- Reference Architecture Fit/Gap Analysis
- Release Plan
- Request for Information
- Request for Vendor Proposal and Response
- Service Level Characteristics Analysis
- Software Distribution Plan
- Source Code
- System Context Diagram
- System Management Plan
- System Test Plan
- Technical Prototype
- Test Cases
- Test Results
- Training and User Support Approach
- Transaction Descriptions
- Usability Design and Evaluation Plan
- Usability Requirements
- Usability Test Plan
- Usability Test Report
- Use Case Mode
- Use Case Validation Report
- User Interface Architecture
- User Interface Conceptual Model
- User Interface Design Guidelines
- User Interface Design Specification
- User Interface Prototype
- User Profiles
- User Support Materials
- Vendor Qualifications
- Viability Assessment
- Visual Resources
The process guidance was closely related to other intellectual capital that had emerged from IBM.
The dynamic stability model  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 , whose goal is responsive, adaptive enterprises, also relies on modular descriptions of capabilities. [p. 72]
-  Pine, B.J., Victor, B., and Boynton, A.C. Making mass customization work. Harvard Business Review (Sept.–Oct. 1993), 108–119.
-  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 .
-  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:
- Impact of Not Having the Work Product
- Reasons for Not Choosing the Work Product
- Development Approach
- Validation and Verification
- Estimating Considerations
- Advice and Guidance
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.
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:
- Objectives and Results
- Key Roles and Responsibilities
- Method Exponent
- Project Manager
- Tools Environment
- Engagement Support Environment (ESE)
- Preparing for the Method Adoption Workshop
- Conducting the Method Adoption Workshop
- Basic Tailoring Procedure
- Results of the Method Adoption Workshop
- 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.
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.