Critical success factors in project management methodology fit
In project management, “one size does not fit all.” Matching the methodology to the needs of a particular project is essential in meeting requirements for cost, quality, and project schedules, and for reducing risk. Because project personnel tend to favor the methodology with which they have the most experience, and because numerous methodologies are available on the market, objective guidance is required to select the most appropriate methodology. The aim of this research is to engage with members of the PRINCE2, Project Management Institute, and Agile communities so as to identify the critical factors guiding the choice of a methodology that fits the characteristics of a particular project. A model is proposed to measure the impact of community assets (expertise invested in a “home ground” methodology) and project factors on the methodology selected and methodological success.
In project management the “one size does not fit all projects” principle is unanimously accepted (Charvat, 2003; Wysocki, 2009). Selecting the appropriate methodology for a particular project is essential for meeting requirements for cost, quality, and project schedules (Charvat, 2003). Conversely, the choice of an inappropriate methodology will increase project risk (Elkington & Smallman, 2002). A methodology can be defined as “a system of practices, techniques, procedures, and rules used by those who work in a discipline” (Project Management Institute [PMI], 2008, p. 438). Because numerous project management methodologies are available on the market, it can be difficult to select the most appropriate methodology. Moreover, because people tend to stick with what they are good at, they favor the project management methods with which they have had the most experience (Boehm & Turner, 2004). Thus, to increase the overall chances of success (or to reduce the risk of project failure), we need objective guidance to select the most appropriate methodology and then to tailor it as necessary to match the needs of a given project. The aim of this research is to engage with members of the PRINCE2 (Office of Government Commerce [OGC], 2009), Project Management Institute (PMI) (2008), and Agile (Agile Alliance, 2001) communities so as to provide a quantitative measure of the project factors that determine methodology fit. The literature on project methodology selection and success is reviewed, and a model is proposed that incorporates quantitative measures of the critical factors in methodology fit and the relationships between them. We first review the literature on project management methodology selection.
Project Management Methodology Selection
Many researchers distinguish between traditional (heavy) and agile (light) approaches to project management (Boehm & Turner, 2003; Charvat, 2003; Highsmith, 2009; Wysocki, 2009).
The traditional approaches rely on a linear or incremental life cycle (Figure 1). These methods are plan-driven and are characterized by a requirement/design/build approach to development (Boehm & Turner, 2004). In this kind of project, the requirements are clearly specified and little change is expected. Thus, the environment is predictable and planning tools can be used to optimize the management of the project. These approaches are usually change-resistant and focus on compliance to plan as a measure of success (Wysocki, 2009). Consequently, they are somewhat prescriptive and are heavy on process and documentation. According to Wysocki (2009), no more than 20% of all projects have the characteristics of traditional projects, but project managers continue to apply these traditional methods on projects for which they are not suited.
On the other hand, agile methods have been developed to respond to the dynamic aspects of the environment. Organizations need short delivery cycles to cope with uncertainty and rapid change in requirements (Wysocki, 2009). Agile approaches are based on an iterative or adaptive life cycle (see Exhibit 1) and are designed to accept and embrace change. They are value-driven rather than plan-driven and use tacit knowledge between team members in place of heavy documentation. In agile methods, the major, upfront, one-time planning task is replaced by an iterative and adaptive series of just-in-time tasks, each of which is executed only when needed. This provides flexibility and adaptability to the project, enabling it to cope more readily with change requests.
Exhibit 1: Traditional and agile life cycles.
Note. From Effective Project Management: Traditional, Agile, Extreme (p. 335), by R. K. Wysocki, 2009, Hoboken,
NJ: Wiley. Copyright 2009 Adapted with permission.
Communities of Practice
The project management field is not a homogeneous one characterized by a common set of principles, guidelines and practices. Rather, it is composed of many different practices, some ad hoc, some developed within communities whose members share certain methodological commitments. “One size” does not fit all project workers. A methodology that is “home ground” to members of one community may be “foreign” and ill-understood by members of another community. We will use the term community assets to refer to the expertise that project workers have invested in a particular community of practice. In this section, we briefly introduce the nature of the community assets associated with three prominent communities of methodology practice: PRINCE2, PMI, and Agile.
PRINCE2 (PRojects IN Controlled Environments), a generic method that prescribes principles, processes, and themes (OGC, 2009), is the de facto standard for project management in the United Kingdom. The use of the term “controlled environments” shows that this method falls into the category of traditional approaches developed to promote compliance to standards in stable/predictable environments.
PRINCE2 is a web of interlinking elements: principles, themes, processes, activities, and recommended actions. The centerpiece of the methodology is the PRINCE2 model of processes and activities that describe human activities (tasks) via a hierarchy of process forward flows, decision points, and feedback loops. Approximately 500 discrete elements and their interconnections are prescribed. In short, PRINCE2 provides a managerial approach that is based on the product (OGC, 2009, p. 64) and highly structured process plans (OGC, 2009, p. 61) that are interspersed with formal decision points (OGC, 2009, p. 91).
The latest version of PRINCE2, released in June 2009, retains the prescriptive and mechanistic tone of its predecessors while promoting added flexibility. Additions include a set of guiding principles and a new chapter on tailoring. The seven principles are: continued business justification, learn from experience, defined roles and responsibilities, manage by stages, manage by exception, focus on products, and tailor to suit the project environment. The current version more fully delivers on claims of being fully scalable and thus applicable to any project.
PMI (PMBOK® Guide)
A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth edition (Project Management Institute [PMI], 2008) constitutes an internationally recognized standard for managing projects that can be used across many types of industries (PMI, 2008, p. 89). Like PRINCE2, it falls into the plan-driven category of process-based project management. Whereas PRINCE2 is more prescriptive, focusing on compliance and control, the PMBOK® Guide is descriptive, including a broader treatment of processes, tools, techniques, and good practices. Nine project management Knowledge Areas are described: Project Integration Management, Scope Management, Time Management, Cost Management, Quality Management, Human Resources Management, Communications Management, Risk Management, and Procurement Management. Each of the nine areas includes processes, activities, tools, and techniques. In total, there are 42 project management processes, categorized into five different groups (Initiating, Planning, Executing, Monitoring and Controlling, and Closing).
Unlike PRINCE2, the PMBOK® Guide directly addresses the judgment processes of project workers. Project managers and teams are urged to select appropriate practices (PMI, 2008, pp. 37–38) by appropriating and adapting the process assets (PMI, 2008, pp. 32–33) that exist in the form of organizational resources embedded in the culture (PMI, 2008, p. 27) of the enterprise environment (PMI, 2008, p. 14). The current version directly addresses “soft” personal attitudes and interpersonal skills via a new appendix on project management leadership, motivation, and related topics that are collectively essential for project management success (McConnell, 1996, p. 249) but are omitted from PRINCE2.
The Agile community was founded in 2001 by devotees of diverse methodologies from around the world who shared similar underlying beliefs and values. Agile is neither prescriptive (like Exhibit 2: Manifesto for Agile Software Development.
Exhibit 2 – Agile Manefesto
PRINCE2) nor descriptive (like PMI's PMBOK® Guide), both of which are based on a set of processes or tools. Instead it is appreciative, based on the values or philosophy that underlies a variety of methods such as XP, Crystal, and Scrum. Agile principles are expressed in a remarkably brief Agile Manifesto (Exhibit 2), the Twelve Principles of Agile Software, the Declaration of Interdependence, the personal statements of 6,000 or more signatories, and various books and research studies.
Comparing the Three Communities of Practice
The three communities of practice (PRINCE2, PMI, and Agile) are compared in Exhibit 3 below.
Exhibit 3: Three communities of methodology practice.
In summary, “one size” does not fit all project workers. Various project management methodologies with different underlying values and principles are available on the market. None of these methods offers a silver bullet capable of destroying all of the enemies of methodology success. Each presents a credible candidate for selection and subsequent adaptation. However, the “process assets” most readily available in a community of methodological practice may or may not be aligned with those best suited for a particular project. The degree of alignment of community assets with project requirements is expected to influence the methodology selected and methodological success/fit. The next section reviews the project factors that guide methodology selection to ascertain if “one size fits all projects.”
Methodology Fit and Success
This section briefly reviews the research on methodology fit. Key research in this area has been produced by Cockburn, Boehm, and their co-authors. Cockburn (2000) explores the principles of methodology design (selection and tailoring) on the basis that “one methodology can't fit all projects” (p.71). He developed four principles—which he later expended to seven in 2007—as follows:
- A larger group needs a heavier methodology.
- A more critical system—one whose undetected defects will produce more damage—needs more publicly visible evidence of correctness (greater density) in its construction..
- A relatively small increase in methodology size or density adds a relatively large amount to project cost.
- The most effective form of communication (for transmitting ideas) is interactive and face-to-face. Group sessions at whiteboards work better than documents exchanged by remote individuals.
These principles can be used as guidance for selecting and/or adapting a methodology. Boehm and Turner (2003) builds on Cockburn (2002) and other studies to describe a risk-based approach. Method selection, engineering, and tailoring are based on an assessment of agility-oriented and plan-driven risk. The risk associated with an inappropriate choice of project methodology is reduced by first assessing project factors to ascertain how well the project fits with either the agile or the plan-driven method. Methodology selection is determined by an assessment of five critical factors (personnel, criticality, size, culture, and dynamism), which are measured on a scale from pure plan-driven to pure agile (Figure 3). The collective match on all five project factors, typically illustrated by superimposing a radar plot on Figure 3, determines the profile of the project. The use of “critical” factors and a risk-based approach offers insightful guidelines for the majority of us who approach systems development from within the confines of a single favorite methodology and therefore may lack an appreciation of how to achieve a “methodologically successful project” (Cockburn, 2007).
Boehm and Turner (2003) support their model by describing projects where the project factors do not favor a pure methodology and where risks are reduced by including practices associated with the opposite (complementary) methodology. This research is supported by a book (Boehm & Turner, 2004) based on extensive conceptual development and empirical case study research into the management of IT projects. Literature searches located related and supporting research in methodology selection factors (Boehm & Turner, 2005; Cockburn, 2007; Highsmith, 2009; Livermore, 2008; Pixton, Nickolaisen, Little, & McDonald, 2009; Tortamış, 2004; and Wysocki, 2009).
Exhibit 4: Project factors in methodology fit.
Note. From “Using risk to balance agile and plan-driven methods,” by B. Boehm and R. Turner, 2003, IEEE
Software, 22, p. 59. Copyright 2003 Reprinted with permission.
The notion of the success of a project can be hard to define and measure (Highsmith, 2009). Traditonal approches usually measure success as the conformance to scope, schedule, and cost, while agile measures success in terms of response to change and value delivered to the customer. Thus there are no consistent measures available across different project management communities. However, Cockburn (2007) suggests a definition of “methodological success” that may be acceptable to all three communities investigated here. He considers that “methodologically successful projects” have the following three characteristics:
- The project was delivered and the product gets used
- The leadership remained intact and did not get fired for their work on the project
- The people on the project would work the same way again
In the research on methodology fit and success, the research of Boehm and Turner (2003) is central to the current understanding of the project factors strategically important in guiding methodology success (Cockburn, 2007). The current research is therefore guided by the measurement of five project factors—personnel (skill), criticality, size, dynamism, and culture (attitude towards change)—on a scale from pure Plan to pure Agile.
The review of project management methodology selection, fit, and success identified two conclusions. The first conclusion, that “one size” does not fit all project workers can be observed in the differences between the methodological commitments of individuals in three communities of methodological practice—PRINCE2, PMI (PMBOK® Guide), and Agile. As mentioned above, the “process assets” most readily available in a community of methodological practice may or may not be aligned with those best suited for a particular project. Project managers and workers may or may not be able to avail themselves of the assets required by a particular project. The degree of match between community assets and project requirements is expected to influence both the methodology selected and methodological success/fit. The second conclusion, that “one size” does not fit all projects, is reflected in the research by Boehm and Turner (2003) on methodology fit. To achieve methodological success (Cockburn, 2007), five project factors must be investigated during methodology selection.
An analysis of previous research revealed that critical factors in methodology selection and success/fit experience have been identified through experience and case study research. The purpose for the research reviewed above is primarily exploratory and descriptive, rather than analytical or predictive (Collis & Hussey, 2003, p.10). No research publications were encountered that developed the operational definitions and related measures that are a prerequisite for quantitative measures. Neither the concept of community assets, nor the five “critical” project factors described in Boehm and Turner (2003), nor measures of methodology selected on a scale from pure Plan to pure Agile, nor measures of methodological success have been expressed in numerical form and employed as the basis for quantitative research. As a consequence, the research stream, although mature, retains a qualitative and descriptive flavor that eschews quantitative measures and predictive models. A quantitative model that employs numerical measures of these concepts and seeks to determine via statistical analysis the strength of the relationships among them has yet to be proposed and investigated. Empirical research based on such a model may reduce at least some of the many things we don't yet know about project management methodology selection and success. Our research targets the four research gaps listed in Exhibit 5.
Exhibit 5: Four research gaps.
A Proposed Model
A model is proposed to identify the impact of community assets and project factors on methodology selected and methodological success (Exhibit 6).
The purpose of the conceptual development of this model and of its empirical evaluation is to test the Boehm and Turner (2003) theory of methodology fit, and the Cockburn (2007) theory of methodological success, by a survey of a sample of project workers. The sample will be chosen from a population of project personnel familiar with one or more of the PRINCE2, PMI, and agile methodologies. This enables us to test the theories within and across the three communities of methodological practice. For each community and for the collective membership of all three communities, the study measures community assets (expertise invested in a “home ground” methodology) and project factors and the degree to which they predict the actual methodology selected and the degree of methodological success achieved.
Exhibit 6: A proposed model.
The research reported here is the first part of a larger study that is proceeding in three stages. In this first stage, we reviewed the literature on project methodology selection and success and proposed a model that incorporates key findings. The results reported here extend existing research in various ways: the model is quantitative and may provide the first predictions based on statistical analysis of the strength of the relationships between theoretical concepts linked so as to form a causal model; the model employs the concept of methodology success to explicitly identify the benefits achieved by methodology fit; the context for application of the model is defined in terms of the communities of methodology practice (ranging from pure plan to pure Agile) from which an appropriate methodology is to be selected; the theories of methodology selection and success are to be tested by theoretical sampling across three well-known communities of methodological practice. In the second stage, all operational definitions and measurable attributes are refined by conducting on-site interviews with project workers. Qualitative data will be gathered on project methodology selection and success in PRINCE2, PMI, and Agile communities of practice. The data will be analyzed, and the findings reported. In the third stage, an online instrument will be developed and members of the PRINCE2, PMI, and Agile communities of practice will be surveyed electronically. The data will be analyzed through the theoretical model proposed in this paper, and the results reported.
Agile Alliance. (2001). Manifesto for Agile Alliance Software Development. Retrieved from agilemanifesto.org
Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. IEEE Software, 22(5), 30–39.
Boehm, B., & Turner, R. (2004). Balancing agility and discipline: A guide for the perplexed. Upper Saddle River, NJ: Addison-Wesley.
Boehm, B., & Turner, R. (2003). Using risk to balance agile and plan-driven methods. IEEE Computer Society, 36(6), 57–66.
Charvat, J. (2003). Project management methodologies: Selecting, implementing and supporting methodologies and processes for projects. New York: John Wiley & Sons, Inc.
Cockburn, A. (2007). Agile software development: The cooperative game. Upper Saddle River, NJ: Addison-Wesley.
Cockburn, A. (2002). Agile software development. Upper Saddle River, NJ: Addison-Wesley.
Cockburn, A. (2000). Selecting a project's methodology. IEEE Software, 17(4), 64–71.
Collis, J., & Hussey, R. (2003). Business research: A practical guide for undergraduates and post-graduate students (2nd ed.). New York: Palgrave Macmillan.
Elkington, P., & Smallman, C. (2002). Managing project risks: A case study from the utilities sector. International Journal of Project Management. 20(1), 49–57.
Highsmith, J. (2009). Agile project management: Creating innovative products. Upper Saddle River, NJ: Addison-Wesley.
Livermore, J. A. (2008). Factors that significantly impact the implementation of an agile software development methodology. Journal of Software, 3(4), 31–36.
McConnell, S. (1996). Rapid development: Taming wild software schedules. Redmond, WA: Microsoft Press.
Office of Government Commerce. (2009). Managing successful projects with PRINCE2. London: TSO.
Pixton, P., Nickolaisen, N., Little, T., & McDonald, K. (2009). Stand back and deliver: Accelerating business agility. Boston: Addison-Wesley.
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® Guide)—Fourth edition. Newtown Square, PA: Author.
Tortamış, P. I. (2004). Light vs. heavy: Which to choose? IMPROQ 2004: Impact of Software Process on Quality Workshop (pp. 6-9). Bornova-Izmir, Turkey: Ege Universitesi.
Wysocki, R. K. (2009). Effective project management: Traditional, Agile, Extreme. Hoboken, NJ: Wiley.
© 2010, Jim Sheffield, Julien Lemétayer
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne, Australia