a new hybrid approach for selecting a project management

© 2015, Grushka-Cockayne, Holzmann, Weisz, and Zitter

Originally published as a part of the 2015 PMI Global Congress Proceedings – Orlando, Florida, USA

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.

Abstract

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 are

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 hybrids 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.

Attribute Levels Budget flexible, variable, fixed

Commitment high, medium, low

Contract Type fixed-price, cost plus, or a hybrid

Customer Type Market, single external, single internal

Duration long, medium, short

Goals well defined, estimated, unclear

Pace time critical, fast, regular

Procedures & Regulations None, standard procedures, highly structured

Resources versatile, standard, unique expertise

Scope modular, multiple delivery units, rigid

Team Availability fully, partially, limited

Team Distribution single-location, multi-location, global

Team Size small, medium, large

Uncertainty ambiguous, predictable, highly predictable

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.

Waterfall Agile Theory of Constraints 1. Critical Path Analysis 1. Sprint retrospective 1. Buffer management

2. Presenting the whole picture 2. Daily stand-up meetings 2. Throughput analysis

3. Focus on project stages 3. Working system from day

one

3. Focus on critical chain on

critical resources

4. Sequential Process

(e.g., progressing one stage at

a time, no overlap)

4. Co-management: Customer

and supplier cooperation

4. Don‘t start things without

finishing others

5. Emphasis on documentation 5. Multi-disciplinary teams 5. Progress—Control by buffer

consumption rate

6. Detailed requirements

specification 6. Self-organizing teams

7. Progress control by earned

value management

7. Progress control by burn

down chart

8. Hierarchical organizational

structure

8. Rapid and flexible response

to change

9. Formal communication 9. Informal communication

10. High-level planning

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.‖

https://en.wikipedia.org/wiki/Extreme_programming



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.

Attributes Case 1 Case 2 Case 3 Case 4 Budget Fixed Fixed Fixed Fixed

Commitment High High High Medium

Contract Type Fixed Price Fixed Price N/A Fixed Price

Customer Type Single Internal Single Internal Market Single External

Duration Medium Medium Short Medium

Goals Well Defined Well Defined Well Defined Well Defined



Pace Fast Time Critical Time Critical Regular

Proc. and Reg. None Highly-structured Highly structured None Specific

Resources Unique Expertise Standard Standard Standard

Scope Multi. Deliv. Units Very Modular Rigid Modular

Team Availability Partially Fully Fully Partially

Team Distribution Single-location Single-location Single-location Global

Team Size Small Medium Small Small

Uncertainty Highly Predictable Highly Predictable Predictable Predictable

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

Attributes Case 1 Case 2 Case 3 Case 4 Waterfall

Critical Path Analysis No No Yes No

Presenting the whole picture Yes Yes Yes Yes

Focus on project stages Yes No No Yes

Sequential process, e.g., progressing one

stage at a time (no overlap) No No No Yes

Emphasis on documentation Yes No No Yes

Detailed requirements specification Yes No No Yes

Progress control by earned value

management No No No No

Hierarchical organizational structure Yes No No Yes

Formal communication Yes Yes No Yes

High-level planning Yes Yes Yes Yes

Agile

Sprint Retrospective No No No No

Daily stand-up meetings No Yes No No

Working system from day one No No No No

Co-management: Customer and supplier

cooperation Yes Yes No Yes

Multi-disciplinary teams No Yes No No

Self-organizing teams No No No No

Progress control by burn down chart No Yes No No

Rapid and flexible response to change No Yes Yes No

Informal communication No No Yes No

Theory of Constraints

Buffer Management No Yes No No

Throughput analysis No Yes No No

Focus on critical chain on critical resources No Yes No No

Don‘t start things without finishing others No Yes No No

Sequential work - No multitasking No No No No

Progress control by buffer consumption rate No No No No

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

Exhibit 5: Attributes-approaches framework mapping.



References

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.

http://agilemanifesto.org/



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.

a new hybrid approach for selecting a project management

Documents