A new hybrid approach for selecting a project management methodology

Yael Grushka-Cockayne

Darden School of Business, University of Virginia

Vered Holzmann

Recanati Business School, Tel Aviv University

Hamutal Weisz

PMzOne Ltd.

Daniel Zitter

PMzOne Ltd.

We propose a multi-dimensional framework for project methods selection, extending the traditional project management trinity of scope, budget, and time, to include multiple attributes on which a project can be characterized. We show how the positioning of a project on the attributes suggests a preferred, and most likely hybrid approach to project management. Through several industry case studies, we explore the ways firms select their approach to project management. We suggest that in most cases, method selection is determined at an organizational level. We hypothesize that firms that do apply a regular process for method selection at a project level see an improved performance in their projects. We show that components of traditional waterfall, theory of constraints, or agile approaches may be appropriate, depending on the constraints a specific project faces. Our implementable tool provides firms with a common framework on which to evaluate projects and select the appropriate method components, what we refer to as an “adaptive blend.”

Introduction

The choice of project management methods, which determines how a project is planned and executed, is of strategic importance to the firm. Ill-chosen management methodologies are often cited among top reasons projects fail (Wells, 2012; White & Fortune, 2002). Špundak (2014), inspired by the Project Management Institute and others, defines project management methodology as “the set of methods, techniques, procedures, rules, templates and best practices to use on a project” (p. 940). While the definition relates to a specific project, project management methodologies are often chosen at an organization level, not considering the specifics of a project at hand (Charvat, 2003; Nelson, 2007). Moreover, firms typically choose a single methodology as a complete end-to-end solution and rarely consider a combination of elements from multiple methods ( Špundak, 2014), although in practice, hybrids might be utilized.

Among the pioneering methods, and perhaps still the most commonly used, is the traditional critical path method (CPM), a key component of the waterfall methodology (Mantel, Meredith, Shafer, & Sutton, 2011). The program evaluation and review technique (PERT), developed around the same time as the CPM, was suggested as better suited for dealing with uncertainty in projects, in particular as it effects project durations. In 1997, Goldratt introduced an adaptation of his theory of constraints (TOC) for project management (Goldratt, 1997). Goldratt’s focus when proposing the adaptation of the TOC was the resources associated with a project, in particular, although not limited to, human resources. The TOC and its principles were especially tailored to address challenges that arise when faced with scarce resources in a project, or resources that are shared across projects.

Shenhar and Dvir (2007), instead of focusing on a single dimension (e.g., uncertainty or resources) propose four dimensions by which a project should be classified: complexity, novelty, technology, and pace. They claim that mapping a project along these four dimensions can inform the way a project should be managed. Loch, DeMeyer, and Pich (2006) argue that traditional methods in project management are not suited for most new project development situations. They distinguish between sources of uncertainty (variation, foreseeable event, and unknown unknowns) and complexity (few interactions of tasks and resources versus many interactions), and provide guidance as to how a project should be managed given the type of risk it entails and its complexity.

The agile approach, as documented in the Agile Manifesto (Agile Alliance, 2001), was proposed as a way to address the needs of highly ambiguous projects, requiring much iteration and dealing with change. For this reason, agile-inspired project management methods have been said to have revolutionized the way software and information technology projects are planned and managed (Stettina, & Hörz 2015).

In the current study, we move beyond a one-size-fits-all solution forselecting project management methods. We decompose the most common project management practices into their fundamental elements, which we call approaches. We offer the multi-dimensional framework, in which we consider fourteen parameters for evaluating a project. For each of these parameters, we identify three potential levels, which may characterize a project. Based on the results of the assessment, a set of approaches is proposed for the project manager. In this vein, our work is aligned with others who have suggested that project management approaches should be adaptive and flexible—suited for specific projects with hybrid options (Shenhar & Dvir, 2007; Špundak, 2014).

The contributions of our work are threefold. First, in unpacking the three main project management approaches (waterfall, agile, and TOC) into modular approaches, we add flexibility and expand the way in which these might be used. Second, the fourteen parameters we identify, along with a description of the possible values they might obtain, add much to the discussion associated with characterizing projects. Finally, the mapping between the parameters’ settings and the choice of methods’ modules provides a practical and structured way for firms to pick and choose the project management method hybrid that best fits their needs.

Project Attributes—Approaches Framework

Our multi-dimensional framework characterizes a project and allows a decision maker (project manager, program manager, or otherwise) to identify the most appropriate mix of processes, hereafter referred to as approaches, for a successful management of any specific project. The framework we offer includes fourteen project attributes for characterization and twenty-three approaches derived from the well-established project management approaches: waterfall, agile, and TOC.

Each of the fourteen project attributes represents a different aspect of the project. A three-level scale is used to rate a project on each attribute. The attributes, and their associated scales, are described below and in Exhibit 1. Note that the attributes are ordered alphabetically and not necessarily in order of importance.

  • Budget is the sum of funds authorized for project execution. It includes the direct and indirect costs, as well as the project management reserves (Project Management Institute, 2013). Project budget is developed within constraints, which can be more or less “soft.” “The budget constraints may be ‘soft,’ in the sense that it is meaningful to adjust the budget depending on what benefits can be secured at different levels of resource expenditure” (Liesiö, Mild & Salo, 2008, p. 679). Therefore, project budget can be fixed, variable, or flexible.
  • Commitment is a feeling of duty that people, in teams and organizations, have to achieve the project goals and objectives, and which is translated into actions that support project success (McDonough, 2000). Project overall commitment represents a high, medium, or low sense of duty by the project's team members to focus on contributing to the overall project goals (Hoegl, Weinkauf, & Gemuenden, 2004).
  • Contract Type is defined within the project procurement management processes and it involves the terms and conditions for administrating the business relations placed on the project team (Project Management Institute, 2013). The contractual relationships can be fixed-price, cost-plus, or a hybrid type that integrates both (von Branconia & Loch, 2004).
  • Customer Type refers to the customer focus in the project planning and implementation, and to the targeted product or service user (Pinto & Rouhiainen, 2002). The project customer can be a single internal, a single external, or the commercial market, where many single end users will buy the product.
  • Duration is defined by A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition as “the total number of work periods (not including holidays or other nonworking periods) required to complete a schedule activity or work breakdown structure component” (Project Management Institute, 2013, p. 537). Classifying project duration as long, medium, or short, is based on a subjective evaluation, relative to the overall activities executed by the organization.
  • Goals are defined within the broader environment of the organization and refer to the desired achievements, outputs, and outcomes (Project Management Institute, 2013). Based on the specific business case analysis, the project goals and objectives can be well defined, estimated, or unclear.
  • Pace refers to the question: how critical is the time frame? While understanding the temporal nature of projects with a definite start and end (Shenhar & Dvir, 2007). Project pace can be time critical when the project duration impacts the achievement of competitive advantage and the need to get to market as soon as possible. In such cases, missing the deadline would result in project failure. The pace can be fast, when constraints on deadlines impose quicker than initially planned turnaround and it can be regular when the project aims to achieve long-term goals and time is not critical to success.
  • Procedures and Regulations refer to the organizational or regulatory infrastructure within which the project is operated. A consistent approach to project strategy and implementation, including planning, executing, and reporting, can be required for specific types of projects (Payne & Turner, 1999). In different organizations and programs, we can find different levels of standardized procedures and regulations, ranging from none specific, through standard, to highly structured and specific regulations for instance, in the case of drug development.
  • Resources, including human resources, equipment, commodities, and material, are required to carry out the project activities. Project resources can be versatile (i.e., one resource can be easily replaced by another); they can be standard (i.e., each resource has its specialty); or they identified as high expertise and unique (i.e., scarce resources—specialized, qualified, certified, professionals—should be carefully assigned to tasks) (Project Management Institute, 2013, p. 269).
  • Scope is defined by the PMBOK® Guide as “the work performed to deliver a product, service, or result with the specified features and functions” (Project Management Institute, 2013, p.554). A rigid project scope implies an inflexible and none divisible set of features and functions. Multiple delivery units implies that the scope is composed of several independent parts that are integrated into a unified deliverable. A modular scope implies that the final product or service is composed of independent segments, or parts, which can be delivered independently or as a unified product (Chen & Liu, 2005).
  • Team Availability refers to the degree to which the project team members are able to start a task when it is called for, whether it is on a planned schedule or at an unexpected time. The number and complexity of external project tasks that the team members are expected to execute usually impacts the degree of the team's availability. The project team can be fully available, partially available, or very limited.
  • Team Distribution is expressed in actual spatial and temporal distance, and many times represents cultural difference (Hogan, 2006). The increasing geographical distribution of work is mainly relevant for information technology projects, although in recent years, it is also evident in other fields (Hinds, 2002). Project teams can work in a single location, in multiple locations, or be distributed globally.
  • Team Size is usually studied with regard to productivity (for example, Pinto & Pinto, 1990; Gorla & Lam, 2004; Rodriguez Sicilia, Garcia, & Harrison, 2012) and yields the understanding that bigger is not always better. The number of team members determines the project team size, classified as small, medium, or large, and is based on a subjective evaluation, relative to the overall activities executed by the organization.
  • Uncertainty relates to situations where the established facts are questioned and the impact of strategic planning on the project performance is raised (Loch et al., 2006; Perminova, Gustafsson, & Wikström, 2008). The degree of uncertainty in the project environment can range from ambiguous, through predictable, to highly predictable.
img

Exhibit 1: Attributes in the attributes-approaches framework.

On the other side of the attributes-approaches framework, there are project methodologies. We follow Charvat (2003) with his definition for methodology as “a set of guidelines or principles that can be tailored and applied to a specific situation. In a project environment, these guidelines might be a list of things to do” (p. 3). Hence, we identified the main processes and techniques in three well-established project management approaches: waterfall, agile, and TOC.

Exhibit 2 presents the main approaches identified in each. Related to the waterfall model, we identified ten separate approaches. The ten approaches related to how waterfall projects get planned, scheduled, monitored, communicated with the project team, and their organizational structure. With the agile mindset, we choose common approaches (nine of them) that are common to most agile practices today, whether Extreme Programming, Scrum, or Kanban. As for TOC, here we identify six approaches, associated today with common TOC implementations.

img

Exhibit 2: Approaches in the attributes-approaches framework.

Our proposal is to characterize a specific project on each one of the fourteen attributes by selecting the most appropriate value on each dimension. This analysis yields a portrait of a project that requires a specific hybrid of approaches for successful project implementation. Appendix A demonstrates the mapping between project characteristics (across the fourteen parameters) and the approaches. In this next subsection, we describe several case studies, which demonstrate how to use the attributes-approaches framework by mapping different project management approaches to project attributes.

Case Studies

Next, we present four industry case studies, which the co-authoring team have been engaged in. Through these case studies, we can see how projects are mapped onto the fourteen attributes, why and how a hybrid of methods was necessary, and how it impacted the project outcome. Exhibit 3 summarizes the mapping of all cases on all attributes. Exhibit 4 relates each case to the methodological components it utilized. Once a project is mapped on to the fourteen attributes, we can utilize the matrix in the appendix to recommend an “adaptive blend.”

Case 1

The organization: An Israeli logistics company delivers merchandise to approximately 300 customers countrywide. Deliveries originate in a central logistic warehouse, following orders received through a third-party company linked to the company's enterprise resource planning system (ERP). Deliveries’ frequency range from one to three times a week per customer on predetermined routes, ensuring maximum efficiency. Itineraries and delivery notes are printed in advance.

The project: The project's primary goal was to replace the printed itineraries and delivery notes with a mobile interface. In addition, the project would serve as a pilot for testing feasibility of ERP-based solutions for mobile for future use in the company.

The project was divided into two stages: the scope of the first stage included the delivery process. The second stage included the returns process. The first stage was scheduled to take place between January and June, 2015. This stage included one major milestone: a pilot would be conducted in April, before rollout, which was scheduled to take place during May and June. The second stage was scheduled from July to October, 2015 and included another milestone for a second pilot, followed by a quick rollout to all customers.

The project budget was estimated at US$41,000, which was determined based on the cost of the mobile devices and cost of work: 550 hours, composed of two full-time programmers (260 hrs.), one full time person (50 hrs.), and one ERP consultant (30 hrs.). This did not include the project manager, who also worked as a system analyst and tester (150 hrs.).

Project summary: The project was (and still is) managed according to internal best practices. The first stage rollout did not meet the plan, due to a technical problem and performance issues, causing a delay in the entire project. Additional causes for delay were:

  • Time to learn the new technology used in the project took almost twice the time estimated.
  • Management decided to delay the rollout by more than three weeks in order to collect additional data from the customers.

The project's second stage is estimated to be complete on time, but with a budget slip of approximately 20%.

Case 2

The organization: In the semiconductor production world, changes to clean rooms are frequent. Every few years, a new and improved process for treating silicon wafers comes along, old machines are moved out of the production floor, and new tools are moved in. The case related to a semiconductor company involved in such clean room clean out.

The project: The project had a very clear objective: move out all old tools, electrical foundations, and pipes from the fabrication clean room, and leave the production floor clear for a new set of tools to come in, starting at a certain, predetermined, date. The company awarded the project to a contractor with whom they had worked with in the past. They agreed on a fixed price project, with a well-defined scope of clearing the clean room and having it ready by the target date.

Project summary: The customer and the subcontractor both appointed project managers from their companies. The customer's project manager worked closely with the team, helping to solve issues as they occurred. Removal of the tools did not happen in the sequence that was planned. Tools that were scheduled for pull out, had to have a “clear to move” sticker on them, which indicates that all electrical and chemical lines to this tool have been cleared. The first three months of the project had a daily plan for the tools that were to be pulled out, but the list kept changing due to the fact that the customer hadn't been able to keep up with his commitments.

Following this troublesome start, every week, a two-hour meeting was held with all the contractor and customer leads, and a revised plan for the following week was created. Tools that had no chemical pipes were pulled out of the clean room instead of the bigger, more complex tools. The project management office (PMO) team kept the big picture of the progress updated. Every week, updates were collected from the field and presented at a weekly meeting. The plan for the next week was created based on this data and the original baseline plan. The sequencing and coordination between the various sub-contractors was also led by the PMO planning.

Daily stand-up meetings were held in the field, to ensure that all were clear on the day's objectives. These meetings proved to be extremely beneficial in aligning the teams in the field to the plan, and resolving issues as they became relevant. The working teams came from four different sub-contacting companies, and each team worked on a different area of the clean room. They tried not to mix but to stay within their own teams. The project managers coordinated the work in the clean room. At the end of each day, additional walk-throughs were conducted to ensure the plan was set for the next day.

Buffer management, daily stand-up meetings, focusing on the entire picture, no multi-disciplinary teams, and weekly rapid and flexible response to change, throughput analysis, and co-management were key in managing this project. The project was extremely successful. It finished with an excellent safety record (no one was hurt), a month ahead of schedule, and met all its objectives.

Case 3

The organization: Lumi Juice was founded in April, 2013 in Charlottesville, Virginia, by entrepreneur Hillary Lewis. Lumi, which stands for “Love U, Mean It,” was to be a new brand of 100% organic juice. To preserve the juices’ nutrients and flavor, Lumi juices would be produced using high-pressure processing (HPP) instead of heat pasteurization (Grushka-Cockayne, 2015).

The project: The scope of the project was to build a fully-functioning manufacturing facility complete with an HPP machine and to design and bring to market a new line of cold-pressed juices. The goal was to put a product on the shelves of a major national retailer as soon as possible, using a limited initial investment of US$500,000 and only two full-time employees. Lumi would also need to file for approval from both the Virginia Department of Agriculture and the Food and Drug Administration to comply with the regulation.

The market was extremely competitive. The market size of the super-premium juice category was estimated at US$1.9 billion. The organic health food market represented a US$32 billion industry. While the organic juice market consisted of well-known national brands such as Naked and Tropicana, these brands were heat pasteurized. In the United States, Evolution Fresh, BluePrint, and Suja were newcomers to the organic juice market. They all used HPP technology and were distributed wholesale. Starbucks bought Evolution Fresh in 2011 and launched it in all stores in January 2014. Hain Celestial Group acquired BluePrint for US$109 million in December, 2012. The San Diego-based Suja generated US$18 million in revenues in 2013 and was forecasting revenues of US$70–80 million by 2015. While all brands were experiencing growth, a clear market leader had not yet been established.

Project summary: On June 28, 2013, Lewis scoped out her project using a traditional waterfall approach. After laying out the dependencies and the expected durations of all the tasks, Lewis estimated that the project would take a total of 49 days to implement, suggesting a launch date of September 4, 2013. Unexpected events (such as delays to the shipment of the HPP machine and the need for an extremely uncommon power supply unit) transpired, resulting in delays. Lewis, serving as the CEO and project manager, and knowing which tasks were critical, was able to focus only on those and respond quickly to changes. The first Lumi Juice was sold at Wholefoods on Oct 29, 2013.

Case 4

The organization: The organization is a worldwide humanitarian assistance organization established over a decade ago, operating in more than 70 countries around the world. The organization's primary purpose is to improve the well-being of vulnerable populations around the world. With over 1,000 employees, the organization is working to alleviate hunger and hardship, rescue people in danger, and provide immediate relief and long-term development support for victims of natural and man-made disasters.

The project: The immediate objective of the project was to transform the organization's human resources to operate globally, in order to achieve consistency, efficiency, agility, transparency, and quality.

Additional objectives for this project were to:

- Establish one system of record for any human resources operational/transactional activity.

- Develop self-service capabilities to reduce human resources manual work.

- Provide accurate and available workforce data to all relevant stakeholders.

- Standardization and automation of processes and data.

Project summary: The project kicked-off after a cloud-based platform (SuccessFactors) was selected as the primary solution supporting human resources strategy and the organizational vision. The project was executed according to the proprietary implementation methodology of SuccessFactors, called BizXpress, which describes what tasks need to be performed and when. This methodology includes a detailed roadmap, as well as a number of tools and accelerators available to SuccessFactors, partners, and customers.

The project was scheduled to start in November 2013 and finish in June 2014, with an estimated budget of US$55,000 and US$80,000 annual license fee. The project team included an executive manager, subject matter experts, a system administrator, a quality assurance team, and a project manager—all belonging to the customer—and a project manager and technology experts from the supplier.

The project was delivered within budget and within the planned timeframe—with only a few weeks delay, but not all of the objectives were achieved. The implementation suffered from inconsistency of data, due to some technical/organizational unforeseen issues, thus, making the reporting not accurate. Overall, the project is regarded as a success both for the customer and the supplier.

img

Exhibit 3: Mapping four case studies on each of the fourteen attributes.

img

Exhibit 4: Mapping four case studies on management approaches.

Analysis of the above case studies reveals correlation between a project's attributes and management approaches when examining the relationship between a project's attributes and the appropriate methodological processes against the project's success.

Conclusions

We present the foundations of our attributes-approaches framework for identifying a hybrid project management approach. Extending the framework trinity of scope, budget, and time, we propose characterizing projects on fourteen attributes, which leads to a set of recommendations for methodological approaches. We present four case studies, which demonstrate how projects map onto the attributes and may suggest hybrid methodologies. Our next steps in this research program are to work with project managers to operationalize our framework in multiple project settings.

APPENDIX A

img

Exhibit 5: Attributes-approaches framework mapping.

Agile Alliance. (2001). Agile manifesto. Retrieved from http://agilemanifesto.org/

Charvat, J. (2003). Project management methodologies: Selecting, implementing, and supporting methodologies and processes for projects. Hoboken, NJ: John Wiley & Sons.

Chen, K. M., & Liu, R. J. (2005). Interface strategies in modular product innovation. Technovation, 25(7), 771–782.

Hinds, P. (2002). Distributed work. Cambridge, MA: MIT Press.

Hoegl, M., Weinkauf, K., & Gemuenden, H. G. (2004). Interteam coordination, project commitment, and teamwork in multiteam R&D projects: A longitudinal study. Organization Science, 15(1), 38–55.

Hogan, B. (2006, July). Lessons learned from an extremely distributed project. Agile Conference, 2006. Minneapolis, MN: IEEE.

Gorla, N. & Lam, Y. W. (2004). Who should work with whom?: Building effective software project teams. Communications of the ACM, 47(6), 79–82.

Goldratt, E. (1997). Critical chain. Great Barrington, MA: The North River Press.

Grushka-Cockayne, Y. (2015). Lumi juice: From concept to store. Charlottesville, VA: Darden Business Publishing. UVA-QA-0835.

Loch, C. H., DeMeyer, A., & Pich, M. (2006). Managing the unknown: A new approach to managing high uncertainty and risk in projects. Hoboken, NJ: John Wiley & Sons.

Liesiö, J., Mild, P., & Salo, A. (2008). Robust portfolio modeling with incomplete cost information and project interdependencies. European Journal of Operational Research, 190(3), 679–695.

Mantel, S.J, Meredith, J.R., Shafer, S.M, & Sutton, M.M. (2011). Project management in practice. (4th ed.).Hoboken, NJ: John Wiley & Sons, Inc.

McDonough, E. F. (2000). Investigation of factors contributing to the success of cross-functional teams. Journal of Product Innovation Management, 17(3), 221–235.

Nelson, R. R. (2007). IT project management: Infamous failures, classic mistakes, and best practices. MIS Quarterly Executive, 6(2), 67–78.

Payne, H. J., & Turner, R. J. (1999). Company-wide project management: The planning and control of programmes of projects of different type. International Journal of Project Management, 17(1), 55–59.

Perminova, O., Gustafsson, M., & Wikström, K. (2008). Defining uncertainty in projects—A new perspective. International Journal of Project Management, 26(1), 73–79.

Pinto, M. B., & Pinto, J. K. (1990). Project team communication and cross-functional cooperation in new program development. Journal of Product Innovation Management, 7(3), 200–212.

Pinto, J. K., & Rouhiainen, P. (2002). Building customer-based project organizations. Hoboken, NJ: John Wiley & Sons.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author.

Rodriguez, D., Sicilia, M. A., Garcia, E., & Harrison, R. (2012). Empirical findings on team size and productivity in software development. Journal of Systems and Software, 85(3), 562–570.

Shenhar, A. J., & Dvir, D. (2007). Reinventing project management: The diamond approach to successful growth and innovation. Boston, MA: Harvard Business Press.

Špundak, M. (2014). Mixed agile/traditional project management methodology—Reality or illusion? Procedia—Social and Behavioral Sciences, 119, 939–948.

Stettina, C. J., & Hörz, J. (2015). Agile portfolio management: An empirical perspective on the practice in use. International Journal of Project Management, 33(1), 140–152.

von Branconi, C., & Loch, C. H. (2004). Contracting for major projects: Eight business levers for top management. International Journal of Project Management, 22(2), 119–130.

Wells, H. (2012). How effective are project management methodologies? An explorative evaluation of their benefits in practice, Project Management Journal, 43(6), 43–58.

White, D., & Fortune, J. (2002). Current practice in project management—An empirical study. International Journal of Project Management, 20(1), 1–11.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2015, Grushka-Cockayne, Holzmann, Weisz, and Zitter
Originally published as a part of the 2015 PMI Global Congress Proceedings – Orlando, Florida, USA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.