Aligning capability with strategy

Introduction

The need to align project delivery capability with corporate strategy is well recognized in the business community (Thomas et al, 2002). Project-based organizations have long been aware of the contribution of project management capability to their overall success, (Turner et al, 2003). However, functionally-based organizations are increasingly realizing that corporate strategy is delivered through projects, and so project management capability is key to their ability to deliver their corporate strategy, (Turner, 1999). To ensure the alignment of project management capability with corporate strategy, choices need to be made:

• (a)     On the one hand, managers must decide how best to use available resources to achieve their strategic intent. They must decide which projects, programmes and portfolio of projects to do to make optimum use of available resources. Projects must also be assessed to ensure they actually did deliver the desired outcomes and that the resources were well used.
• (b)     On the other hand, organizations must ensure they have the project delivery capability to deliver the chosen projects, programmes and portfolios.

For both these reasons, organizations need to have ways of categorizing their projects. They need to be able to categorize projects to be able to prioritize projects to decide which ones to do, and to ensure they have appropriate skills within the organization to do the chosen projects.

In this paper, we present results of an investigation undertaken with the support of the Project Management Institute (PMI^®) Research Program into the ways in which organizations categorize their projects and project management capability in order to ensure alignment with corporate strategy. In the next section we consider the use of categorization systems within organizations. We then give a brief overview of how we conducted our research. We found that organizations categorize projects for the two broad reasons given above. We describe the nature of those purposes, and how organizations describe and use them, presenting a purposes model derived from the research. In order to be able to categorize projects, they must be assigned attributes. We thought at the start of the research that attributes would be linked to the purposes for which projects were categorized. That turned out not to be the case. All models of attributes are used for different purposes in different organizations. We present our attributes model and describe how organizations use the attributes. We then describe how an organization can develop a categorization systems for projects and draw conclusions about the use and value of project categorization systems in organizations.

The use of categorization systems in organizations

The need to categorize things seems to be an almost innate part of human nature, (Taylor, 1999; Bowker & Star, 2000). Language itself is a categorization system, and very little in the world around us is not categorized, that it seems to be an unconscious part of our thought processes. (In this paper we refer to categorization systems of projects rather than classification systems. Classification systems, such as the classification of species, sort things into mutually exclusive sets, whereas categorization systems sort things into sets of items with similar properties. Under a classification system, an item can belong to only one set, whereas under a categorization system, an item can belong to several sets. That is what is appropriate for projects (Crawford et al, 2002).

A categorization system for projects is thought by many to be a holy grail, an aid to both practitioners and researchers, (Crawford et al, 2002). The project management literature has tended to focus on capability development and tailoring management style to suit project type, (Dvir et al, 1998; Shenhar, 1998; Payne & Turner, 1999; Youker, 2002), whereas the project portfolio literature has focused on classifying projects for the purpose of prioritizing them, (Cooper et al, 1997; Aalto, 2001).

Bowker and Star (2000) identify three challenges in developing a categorization systems for a work environment: comparability, visibility and control.

• (a)     Comparability: We are trying to develop a system to provide comparability between projects in some way, and this requires some standardization of the language. This enables people to:
  •     facilitate communication, ensuring understanding among users,
  •     move between projects, even internationally, without having to learn new terminology,
  •     draw on lessons learned from similar projects, facilitating knowledge management and increasing the likelihood of success.
•           However, standardisation poses its own challenges. Reducing the variety and complexity of reality to a small set of categories requires considerable simplification, and a rigid adhesion to a set of categories and rules for categorizing can lead to inappropriate decisions.
• (b)     Visibility: Categorization greatly enhances visibility. When something is categorized it becomes visible, and entities that are not identified by the categorization scheme can be ignored and become invisible.
  There are several issues associated with visibility:
  •     What territory is covered by the categorization system? In a project context, this means deciding which activities will be included or excluded from the system.
  •     Will non-project activities such as operations and maintenance also be included?
  •     Which projects should be included or excluded?
  •     Which types of projects are sufficiently different to merit identification within the system?
  •     Which attributes should be used to identify these differences? The system needs to identify projects that are different and attributes that differentiate, in other words, to identify differences that make a difference.
• (c)     Control: Once an organization develops a system, its design needs to be controlled. Having control of the system means being able to exercise discretion over interpretation of the rules of categorization. A categorization system is a representation of reality. As such, it is necessarily a simplification. Designing and using a categorization system always requires some degree of judgement, about the identification of the categories and the rules for categorizing. The rules will never be perfectly unambiguous. Some judgement will also be necessary in their interpretation and application. Judgement must also be used to account for unforeseen or changing circumstances. Some discretion is necessary, which in turn will require both judgement, which is often based on experience and training, and organisational power.

Ideally these three challenges will be in balance, but in reality compromises are necessary:

•     high levels of visibility and comparability reduce control,
•     increased control reduces comparability as variance is introduced into the system,
•     increasing the number of attributes increases visibility but reduces control.

The purpose of a categorization system is a primary factor in the shaping of the system. A system with multiple users with different needs can result in conflicts that, if not resolved, can become embedded in the system and therefore affect its functionality. In the development of any categorization system decisions have to be made in choosing categories, which in turn determine what is to be a visible part of the system. Too strict a categorization can lead to the loss of user discretion, particularly in a work setting. This loss of autonomy is generally not evenly distributed across the organisation as “the loosest [categorization] of work is accorded to those with the most power and discretion who are able to set their own terms” (Bowker & Star, 2000).

A categorization system must be accepted by those whom it affects for it to work effectively. Implementing or changing an existing project categorisation system is an organisational change. As such, its success depends on issues of ownership, process, and perceived interests. The system must accurately reflect the participants' real-world experiences. This is not always easy as different users may have different perceptions of the system and its fit with work practice. There is often a tension between clear, consistent and scientifically based categories, on the one hand, and intuitive, common sense and well-accepted terminology on the other hand.

The authors were charge by the PMI research committee to develop a categorization systems for projects that meet these requirements.

Methodology

The focus of the research was practical, developing a categorization system of use to PMI's members. There were five steps to the research:

1. First, we conducted a literature search covering the nature of classification and categorization systems, and of systems that had currently been developed for project management. This was reported at PMI's research conference in Seattle in 2002, (Crawford et al, 2002).
2. Next we conducted focus groups within organizations. Nine groups in total were conducted in Europe, North America and Australia. A range of organizations took part, including two financial services companies, three engineering design and construction departments of large public utilities, two consulting firms, the project arm of an international aid organization, and a group of information systems consultants. That gave a broad range of practical experience that increased the applicability of the results. Questions asked in the focus groups are listed in Exhibit 1.
3. Based on the results of the literature search and focus groups, a web-based questionnaire was developed. A total of 119 usable responses from around the world were received. The information gathered by the web-based questionnaire is shown in Exhibit 2.
4. A authors then met to synthesise the results so far and develop a preliminary model. Protocols were also developed for validation meetings with the focus group companies.
5. Finally, validation sessions were held in seven of the nine organizations that had participated in the focus groups. (It was not possible to reassemble the group of information systems consultants within the time frame, and with the ninth group the validation exercise had to be conducted with the participants individually rather than as a group.) The information sought in the validation meetings is in Exhibit 3.

Exhibit 1: Questions asked in the focus groups

Exhibit 2: Information gathered by the web-based questionnaire

Exhibit 3: Information sought in the validation meetings

The model

The model developed showed that there were two components of the categorization system in use in most companies:

1. The purpose of for which the categorization systems is used.
2. The attributes used to categorize projects.

For both these components we developed a mind map, Exhibits 4 and 5 respectively. These mind maps are, effectively, decision trees from which to develop a categorization system in a given organization. Both of these mind maps were also converted to HTML versions, for easier interrogation as web pages. Exhibits 6 and 7 show one page from each map respectively. It is intended that these web-pages should be made available to PMI members.

Purposes of categorization systems

The mind map for the organizational purposes to which categorization systems for projects are put is shown in Exhibit 5, and a page from the corresponding HTML version in Exhibit 6. There are two major branches, and one minor branch, representing three purposes of such systems:

1. Strategic alignment: Organizations need to categorize projects to:
   • assign priority for projects within their investment portfolio,
   • track the efficacy of their investment in projects,
   • create strategic visibility.
2. Capability specialization: Organizations need to categorize projects to:
   • develop project delivery capability within the organization,
   • assign appropriate resources and tools to the management of projects.
3. Promote the project approach: The minor need is to:
   • Decide that the work being done is projects, and differentiate projects from operations,
   • differentiate projects, programmes and portfolios of projects,
   • provide a common language for project management within the organization.

Exhibit 4: The organizational purposes mind map

Attributes of projects

The mind map of attributes of projects for categorizing projects is shown in Figure 5, and a page from the corresponding HTML version in Exhibit 7. Each branch in Exhibit 5 had several sub-branches, but they cannot be shown in this figure. Exhibit 7 shows there are eight sub-branches for branch 1. The fourteen branches and corresponding sub-branches were compiled from the literature review, focus groups and answers to the web-based questionnaire. We also added branches and sub-branches from our own experiences. The 14 branches covered all the project categorization systems we identified. However, at times the sub-branches had to be simplified. People using this map will need to use it as an aide-memoir and guide, rather than a definitive answer. It differs in this way from the purpose map, which was fairly comprehensive.

Exhibit 5: The map of attributes for building project categorization systems

Exhibit 6: Sample web-page of the purposes map

Exhibit 7: Sample web-page of the attributes map

Complex systems

In reality, none of the organizations we studied used a simple one- dimensional model for categorizing projects, but instead multiple dimensional models. The models were of three types:

1. Hierarchical systems: Projects were categorized in one way, and then the individual categories categorized further, sometimes in different ways. For instance, at the top level projects may be categorized by size, and then large projects further categorized in one way, medium projects in another and small projects in another.
2. Parallel systems: Several sets of attributes were assigned to every project. For instance, projects might be categorized by complexity, technology and strategic importance.
3. Composite attributes: An example of a composite attribute would be complexity. Many organizations used one dimension for complexity, but some used several classes of attributes to define complexity. In the web-based questionnaire, those organizations that classified projects by complexity (57 out of 119) used an average of 5 attributes to define complexity.

Conclusions

We offer this model to organizations as a tool to examine their existing project systems, to better understand the way they work, and as a guide to redesign them. Most organizations already have a project categorization system, whether formal or informal. The model could also be used in a green-field site to design a categorization system from scratch.

The design or redesign of a system would start with the identification of organizational purposes to which the system would be put, starting at a strategic level and working down to an operational level, aligning capability with strategic intent. The next step would be to select attributes that would be most appropriate for the intended uses. To balance comparability, visibility and control, the attributes should be chosen by working with focus groups of users, and validating the final model with them. The experience from our research is that focus groups are a powerful tool for this purpose. The analysis of an existing system would start from the other end, investigating how projects are currently categorized, and the investigating the purposes to which they are put.

Project categorization systems are a powerful tool for aligning capability with strategic intent. We offer our model as a too to enable organizations to analyse and improve their existing systems.