The diversity of IT projects frustrates any direct attempt to systematize the processes used for their development. One size just won’t fit all. Even three or four sizes aren’t enough because the set of projects doesn’t neatly divide into three or four simple categories. A more flexible and configurable approach to process guidance is needed, a way of tailoring the process to the needs of each particular project.
To make processes configurable there must be some concept of modularity. It must be possible to select different subsets of the available modules and put them together in a coherent way. The scheme proposed here is very simple. The main focus is on the tangible things produced. They are identified (at a certain level of granularity) as “work products” and a descriptive module created for each distinct type. The modules, called Work Product Descriptions (WPDs), describe what the work product is, why and when it is needed, and how it is produced. The WPDs comprise an important subset of the configurable process framework. The process is configured to a particular situation by deciding which work products need to be produced and then making choices about sequencing and phasing.
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.
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.
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 199496 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.
Modularity is a prerequisite for reuse as well as for configurability, and reuse has become an important further motivation. Instead of creating their own independent, overlapping, and mutually inconsistent methodologies, groups must now fit their guidance into the framework, reusing WPDs where appropriate and only extending with genuinely new material (for example, specialist WPDs, or specialist techniques for existing WPDs).
A modular process framework is therefore also a tool for integrating disciplines, and for helping disparate groups understand what each other has to offer. The many specialist groups that thrive in a complicated organization like IBM used to evolve their own approaches and apply them, often with great success, to their specialized set of projects. Without an integrating framework it was difficult to take part of this expertise and make it available for general use.
The WPDs are also an indexing mechanism into the intellectual capital that is increasingly an important resource in project work. By standardizing on a limited number of WPDs it is easier to recover examples that may be useful on future projects, and to search for examples that may be useful on projects just starting. The IBM Intellectual Capital Management system and associated processes are described in [2].
Perhaps the most difficult issue has been cultural. Everywhere the tailoring approach has been used it has proved successful. It is a way of giving ownership, indeed of forcing ownership of the process on to the development team. Nevertheless, managers are sometimes still uncomfortable. Surely, they argue, if the aim of methods is to make things more standard, we shouldn’t encourage every project to adapt the method. These managers would prefer the simplicity of a single uniform process. The reality is that efforts to make everything uniform never work. They fail not because a given process is not good enough, but because it is too rigid, because it does not adapt easily enough to the inescapable diversity of IT projects.
Work Product Descriptions
A WPD is very simply a 310-page description of a project artifact that uses the following headings:
- Description
- Purpose
- Impact of Not Having the Work Product
- Reasons for Not Choosing the Work Product
- Validation and Verification
- Estimating Considerations
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.
A dependency diagram shows the natural flow through the work products but it does not specify the exact order in which they are produced. Often early drafts of related work products are incrementally improved together. Sometimes an upstream work product is reverse engineered from a naturally downstream work product.
The work product view of a process describes what might be stored in a project repository. It addresses the question, “What will be produced, independent of when?” Clearly the material in a repository can be developed in different orders, and a description of one or more plausible sequences is a valuable part of any method. So, more is needed than just WPDs.
The work product approach to configurable processes is an attempt to structure and manage the knowledge in a very complex domain, knowledge about how to do IT projects.
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.
Configuring the Process Framework
Configuration plays a central role in methods based on WPDs. This represents a psychological shift in the role of method. All too often, deviation from a standard methodology is seen as an imperfection, as an unwelcome compromise (despite the fact it always happens!). This attitude is sometimes encouraged by methodologists who, as a group, are not noted for their flexibility. Instead, adapting to particular circumstances should be the norm, and should be an integral part of any method and of the way it is taught.
The usual context for configuration is a project. As the project starts key members of the project team configure the method to their needs and circumstances. The early and central question is, “What work products are needed on this project?,” not just, of course, what is to be delivered, but also what is to be produced along the way. Tailoring or configuration work is done early during the proposal phase and revised when the project starts. If there is a well-established matching engagement model, the simplest approach is to amend the associated list of WPDs. Work products are usually selected or deselected in groups. Dependency diagrams help people visualize the impact of their decisions.
Figure 3 shows the form of a spreadsheet that can be used to record the results of the configuration. The spreadsheet starts from a standard list of WPDs, either the full list or the WPDs associated with an engagement model. Some groups also use a standard questionnaire to help with their configuration.
The Adopted column indicates whether the work product will be produced on the project. The Asset/ICM column identifies material that can be used as a starting point or as a useful reference (ICM means Intellectual Capital Management).
The sections of the WPDs named ‘Impact of Not Having This Work Product’ and ‘Reasons for Not Needing This Work Product’ give advice about omissions. Although the choice of work products is central, the other components of the method must also be tailored. Intellectual capital can also be associated with the process, so the advice is not just, “Do X to produce Y” but potentially “Do X to produce Y using Z as an example and W as a further guide.”
The many factors that contribute to the variation among projects are exactly the factors that influence tailoring decisions. These factors include project scope, client responsibility, experience of the team, quality of input materials, and areas of project risk. The analysis of these factors and the consequent decisions about work products are a very efficient way of understanding and planning a project.
A second context for configuration is the development of new specialized method guidance. For example, it may be worthwhile to produce specialized guidance for projects that use a particular package or deliver a particular service offering. The idea is these projects will tailor in much the same way, so it will be more efficient to do the common part of the tailoring work only once. Each project may still have some minor adjustments to make, but each starts from a base that is much closer to its needs. Given the competitive pressures that tend to shorten the period during which a package or offering has a clear market advantage, this prepackaged configuration can help an organization to scale up its delivery capability more quickly.
Work Product Descriptions Granularity
If you are developing a process framework based on WPDs, a frequent question is, “Should there be one or two work products to cover this material?” The choice is often rather arbitrary—the following guidelines may be helpful, if only to establish a consistent style when working with WPDs.
Many work products are working documents that evolve during the project. The intermediate versions are not normally treated as separate work products. However, it is better to distinguish two work products if the earlier form has a distinct identity and needs to be referred to independently even after the later form has been produced.
Two work products can always, in principle, be combined into one. If responsibility for the two parts is usually with the same person, if it is rare to do one part without the other, if we are happy for the two parts to be versioned together, then combining them is probably a good idea.
Two WPDs may be combined into a single, more abstract WPD. For example, we may choose to have a single Test Plan WPD instead of separate System Test Plan and Integration Test Plan WPDs. In this case projects may still create two work products, each corresponding to a single WPD. The criteria are again pragmatic and depend on the guidance we intend to produce. If, for example, the Purpose, Notation, Example and Development Approach are different for a System Test Plan and an Integration Test Plan then the WPDs should be separate. If most of the content is the same, the answer is apparent.
Knowledge Management
Finally, we can look at all this from a knowledge management perspective. The work product approach to configurable processes is an attempt to structure and manage the knowledge in a very complex domain, knowledge about how to do IT projects. The structure helps with the analysis of a project and the identification of what knowledge is appropriate and useful. The WPDs are themselves part of this knowledge. And, as already noted, they are an indexing mechanism for examples, templates, and related material. They therefore play a pivotal role in organizing knowledge about IT projects.
Figures
Figure 1. List of 96 WPDs used in IBM custom application development (v1.1)
Figure 2. Fragment of dependency diagram showing work product descriptions associated with usability.
Figure. Paper prototype of an order management user interface.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment