Sie sind auf Seite 1von 53

Complementing agile software

project management methods with


plan-driven components.

August 15, 2011


Student: S. de Koning
ANR: 962000

University supervisor: Dr. M.A. Jeusfeld


Company supervisor: M. Schapendonk MSc
MSc Thesis Information Management, Tilburg University.
August 15, 2011

Management Summary
For several decades software project management methods have been developed and used. Plan-driven methods like
the waterfall method and its successors have been followed by agile software project management methods in the
1990s and both have existed concurrently since. The last decade however, hybrid software project management
methods have emerged. This thesis studies four cases where hybrid forms of software project management methods
have been used to distinguish when it is necessary to complement agile software project management methods with
plan-driven components. The research question this thesis answers is:
How and when should agile software project management methods be complemented with plan-driven components
to result in a better software project outcome?
Resulting from this research question five propositions were formulated based on the five dimensions discussed
later.
After studying several existing software project management methods (plan-driven, agile and hybrid) the research
method is explained. Using the case study method four cases are studied following a research framework containing
five dimensions and 19 factors divided among these five dimensions. The five dimensions are size, criticality,
culture, dynamism and personnel. The 19 factors are application size, man-hours, project type, team size,
complexity, loss scale, time constraint, organization type, company growth stage, trust, organizational culture,
Cockburn dynamism scale, extended Cockburn method skill rating scale, experience, education, project manager
type, CRACK customer, project personnel turnover and familiarity with technology. By studying several sources of
information like documentation, interviews, company websites and such these factors have been judged on their
significance and influence.
This thesis studies four different cases at four different organizations in the Netherlands. All four projects
were more or less successful considering budget, deadlines and satisfaction. Case A studies a relatively small and
short project where a slightly adapted form of Scrum was used. Case B studies a larger project where a very
pragmatic software project management method is used using a combination of Topaz and Scrum elements. Case C
studies a large project at a Dutch university where the project is managed using a combination of Prince2 and Scrum
for development. Case D studies a project at a governmental organization where a workflow management system
was implemented using Prince2 as the overall software project management method in an agile way and using
Scrum for the managing product delivery component in Prince2. These four cases were studied and it was
determined how and why they used / would use the 19 factors in their software project management method decision
when choosing for a more agile or a more plan-driven method.
After studying the cases it can be concluded that nine out of 19 factors are significant factors in the decision
for the place on the planning spectrum of the most suitable software project management method where a positive
influence means the method should be more plan-driven and where a negative influence means the method should
be more agile. Team size, loss scale, organizational culture and project manager type have a positive influence and
organization type, trust, Cockburn dynamism scale and the extended Cockburn method skill rating scale have a
negative influence on the amount of plan-driven components. Complexity is a significant factor but whether it has a
positive or negative influence cannot be agreed upon.
The factors application size, man-hours, time constraint, education, project personnel turnover and
familiarity with technology all are judged as not significant. The significance of the factors project type, company
growth stage, experience and CRACK customer could not be determined because of contrasting findings.
All five dimensions contain factors that have been proven to be significant. The culture dimension was
especially considered to be significant. The five propositions concerning the five dimensions are therefore
determined to be correct which results in the answer for the research question. The significant factors can be used to
determine how and when the software project management method should be complemented with plan-driven
components.
The knowledge gathered about the factors in this thesis can be used as a base for future research since the
significance of several factors could not be determined. It is also advised to test these variables in different
situations, other countries, with other developers and customers and using other (hybrid) software project
management methods to increase the external validity.

S. de Koning; MSc Thesis Software Project Management Page 2


August 15, 2011
In practice one could use this thesis by considering the nine significant factors before choosing the
(combination of) software project management method(s) for a project. Culture is an important dimension when
considering the software project management method so one should certainly consider this factor. If the application
of an agile method is preferred but the culture in the customer organization is control and order oriented, one should
consider adding components from a plan-driven method like Prince2 like has been done in case D therefore
customizing the hybrid software project management method. This can prevent problems and improve control while
still maintaining the speed and agility of a method like Scrum. Furthermore, a developer could influence the factors
and thus improve the chance on a successful application of a software project management method.

Keywords: Software project management, software development, agile, plan-driven, hybrid, planning spectrum,
case study.

S. de Koning; MSc Thesis Software Project Management Page 3


August 15, 2011

Preface
The first experience with the topic of software project management was during a premaster course in the beginning
of 2010. It was quite a demanding course but was also very interesting. When I encountered the topic again as a
possible MSc Thesis topic at Whitehorses I was directly interested. Senior Consultant Martin van Borselaer had
written an interesting whitepaper discussing the combination of Prince2 and Scrum in one of his projects and
introducing the subject of hybrid software project management to me. Luckily Whitehorses was also interested in
expanding the knowledge about hybrid software project management methods and the result is the MSc Thesis you
are now reading.
During the four months writing this thesis, several people helped me who I would now like to thank. I
would like to thank Dr. M.A. Jeusfeld from Tilburg University for his supervision and Martin Schapendonk from
Whitehorses for his feedback and help during the process of writing my thesis. The support from everybody at
Whitehorses in selecting cases, approaching clients and providing information was very helpful and important for
this thesis. Of course I would also like to thank the clients who were willing to participate and were able to find time
in their busy schedules for the interviews. Thanks to study association Asset | SBIT for organizing the event where I
got the opportunity to get in touch with Whitehorses to arrange my internship. And last but not least many thanks to
family, friends and the other master students for their support and help.

S. de Koning, August 15, 2011

S. de Koning; MSc Thesis Software Project Management Page 4


August 15, 2011

Table of Contents
Management Summary ..................................................................................................................................................2
Preface ...........................................................................................................................................................................4
1. Introduction ...........................................................................................................................................................6
1.1 Problem introduction ...........................................................................................................................................6
1.2 Research question and propositions .....................................................................................................................7
2. Theoretical background .........................................................................................................................................8
2.1 Software Project Management .............................................................................................................................8
2.2 Plan-driven approaches ........................................................................................................................................9
2.3 Agile approaches ............................................................................................................................................... 11
2.4 Hybrid approaches ............................................................................................................................................. 13
3. Research method.................................................................................................................................................. 15
3.1 Case study method. ............................................................................................................................................ 15
3.2 Developing the theory. ....................................................................................................................................... 15
3.3 Selecting the cases. ............................................................................................................................................ 17
3.4 Data collection ................................................................................................................................................... 17
3.5 Processing case findings .................................................................................................................................... 18
4. The cases ................................................................................................................................................................. 19
4.1 Introduction ....................................................................................................................................................... 19
4.2 Case A ............................................................................................................................................................... 19
4.3 Case B ................................................................................................................................................................ 22
4.4 Case C ................................................................................................................................................................ 25
4.5 Case D ............................................................................................................................................................... 29
5. Results ..................................................................................................................................................................... 34
5.1 Introduction ....................................................................................................................................................... 34
5.2 Size .................................................................................................................................................................... 34
5.3 Criticality ........................................................................................................................................................... 36
5.4 Culture ............................................................................................................................................................... 36
5.5 Dynamism .......................................................................................................................................................... 38
5.6 Personnel ........................................................................................................................................................... 39
5.7 Conclusion ......................................................................................................................................................... 40
6. Conclusion ........................................................................................................................................................... 41
6.1 Discussion .......................................................................................................................................................... 41
6.2 Contributions to research ................................................................................................................................... 42
6.3 Contributions to practice .................................................................................................................................... 42
6.4 Limitations and future research ......................................................................................................................... 44
References ................................................................................................................................................................... 45
Appendix A: Case study interview / data gathering questions. ................................................................................... 48
S. de Koning; MSc Thesis Software Project Management Page 5
August 15, 2011

1. Introduction
Chapter 1 will introduce the problem that has been studied in this thesis and will pose the research question
and propositions.

1.1 Problem introduction


For decades there has been a widespread view that the best way to manage software projects was using careful
project planning, formal quality assurance and controlled and rigorous software development processes (Boehm,
2006). This approach involves significant overhead in planning, designing and documenting the system. This is a
reasonable approach for large software systems with many different people working on it but applied to small and
medium-sized systems this approach involved relatively large overhead and the time needed for making plans and
describing requirements would be larger than the time needed for the actual creation and testing of the system.
Another problem that could be encountered when using the plan-based approach is that requirements can change
during the project which can result in delivering a product that no longer answers the client‟s needs or in major
rework resulting in delays, budget overruns etcetera (Sommerville, 2007).
The reaction to this problem was the development of agile software development methods. Several agile
methodologies have been developed. Some examples of agile methodologies are: Extreme Programming (XP),
Crystal methods, Lean Development, Scrum, Feature Driven Development, DSDM and Adaptive Software
Development (Chan & Thong, 2009; Sommerville, 2007)
These methodologies all differ in some way but they also have several characteristics in common. They all
focus on: customer involvement, early and incremental delivery, “people not process”, embracing change and
maintaining simplicity (Kent Beck et al., 2001; Chan & Thong, 2009; Sommerville, 2007)
Although these agile methodologies claim to be the answer to the problems inherent to waterfall methods
and alike, there are several critics who are less positive about the new agile methodologies (DeMarco & Boehm,
2002; Petersen & Wohlin, 2009; Stephens et al., 2003). They for example argue that with agile methodologies,
speed is being improved at the cost of higher risk. This risk evolves from “trading off explicit knowledge captured in
documentation for tacit interpersonal knowledge” (DeMarco & Boehm, 2002) which can negatively influence the
project result when human capital is lost or knowledge is lost in some other way. Also, in practice, few
organizations are able, psychologically or technically, to adopt agile development approaches (Qumer & Henderson-
sellers, 2008). DeMarco and Boehm (2002) suggest a hybrid approach “where agile methods incorporate some
techniques from plan-based development” (Sommerville, 2007). Boehm (2002) states in another paper: “Hybrid
approaches that combine both methods are feasible and necessary for projects that combine a mix of agile and plan-
driven home-ground characteristics” (Boehm, 2002). M. and T. Poppendieck also advise to look for the balance
point of the lean principles in agile software development and to avoid swinging from high to low ceremony and
back indirectly suggesting combining different approaches and using the parts appropriate for your project / business
(M. Poppendieck & T. Poppendieck, 2003).
This can be visualized by using the planning spectrum made by Boehm (2002). A graphical representation
of the planning spectrum can be seen in Figure 1. Agile methods like XP and Scrum are positioned on the left while
plan-driven methods are positioned on the right. Between these extremes, there are possibly a lot of projects that
need a software project management method that is positioned somewhere in the middle.
Adaptive SW Milestone Milestone Inch-pebble
development risk-driven plan-driven ironbound
Hackers XP models models contract

Agile methods Plan-driven methods


Figure 1: The planning spectrum Source: Adapted from (Boehm, 2002)

These findings from literature seem to ask for a hybrid software project management method using agile
methodologies like XP or Scrum to create speed and high customer satisfaction and more classical software project
management methods like for example Prince 2 to provide some benefits that come with plan-driven approaches.
S. de Koning; MSc Thesis Software Project Management Page 6
August 15, 2011
This thesis studies four cases where an agile (one case) or hybrid (3 cases) software project management
method has been used and compares them in order to distinguish which factors and characteristics define if an agile
software project management method should be complemented by plan-driven components.

1.2 Research question and propositions


The research question that follows from the previous problem description:

How and when should agile software project management methods be complemented with plan-driven components
to result in a better software project outcome?

The following five propositions are the result:


1. When a software project increases in size, the necessity to complement agile software project management
methods with plan-driven components increases.

2. When the stakes are higher in a software project (criticality), the necessity to complement agile software project
management methods with plan-driven components increases.

3. When the culture is more order and control oriented, the necessity to complement agile software project
management methods with plan-driven components increases.

4. When there are high rates of change (high dynamism) in a software project, the necessity to complement agile
software project management methods with plan-driven components decreases.

5. When project personnel has low/medium skill levels, the necessity to complement agile software project
management methods with plan-driven components increases.

The five propositions have been based on Boehm and Turner‟s paper and book on balancing agility and discipline
(Boehm & Turner, 2003a, 2004a) where they propose size, criticality, culture, dynamism and personnel as critical
decision factors.

S. de Koning; MSc Thesis Software Project Management Page 7


August 15, 2011

2. Theoretical background
Chapter 2 will provide the theoretical background for this thesis. Paragraph 2.1 will discuss the different
software project management movements after which the plan-driven approaches will be discussed in
paragraph 2.2, agile approaches in paragraph 2.3 and hybrid approaches in paragraph 2.4.

2.1 Software Project Management


There are currently two main distinctive approaches in software project management methods; plan-driven methods
and agile methods (Boehm & Turner, 2004).
The first approach, plan-driven methods, has been around the longest. Starting with Royce (1970) who
designed the classic waterfall model up to the more recent plan-driven methods like Prince2 the plan-driven methods
have evolved and are still being used up to today. These plan-driven methods are considered as the traditional way
to develop software and are based on standard, well-defined processes, steps, documentation and more. This
documentation and the thorough preparation (gathering requirements and designing systems) before starting with
developing have certain benefits but also certain disadvantages.
Thorough documentation enables traceability and verification of every step in the process. The
standardization of steps and processes provides a high repeatability and almost every person with knowledge about
the standard method will be able to find information about the project and track progress. Tacit knowledge can be
externalized using the SECI-model (Nonaka, 1994) and can therefore possibly also be documented. This makes it
easier to introduce new project members. Loss of key personnel will in these cases not necessarily doom the project
since a lot of their explicit and tacit knowledge is being documented. The explicit use of risk management also
improves identifying risks and mitigating them. Through the years the evolution of the plan-driven methods has
involved integrating best-practices which improved the stability and reliability of the methods.
There are also several disadvantages to plan-driven methods. The heavy and large plan-driven software
project management methods result in significant overhead. When too strictly applied, this also leads to a large
amount of documentation which will never be used but is only produced because the method requires it. This can
obstruct innovation. People using heavy plan-driven methods “run the risk of becoming documentation generators
instead of software developers” (Boehm & Turner, 2004). Plan-driven methods are also less suited to deal with
changing requirements. Often these projects put a lot of effort in defining requirements and documenting these only
to find out the original situation has changed or requirements have changed when delivering the product
(Sommerville, 2007).
The second approach, the agile approach, is relatively young compared to the plan-driven approach. In the
1990s a number of software developers designed several agile methods (Scrum (Schwaber, 1997), XP (Kent Beck,
1999a) and many more) in response to the heavy-weight plan-driven methods. In February 2001, this resulted in the
Agile Manifesto (Kent Beck et al., 2001):
“We are uncovering better ways of developing software by doing it and helping others do it. Through this
work we have come to value:

Individuals and interactions over processes and tools


Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

This Agile Manifesto was the result of a 2-day meeting of 17 software development method engineers who shared
the same basic feeling about software project management and translated this into the manifesto. Since 2001 agile
methodologies have continued to mature and to be adopted.
Agile methods commonly use very lightweight processes and work with short increments each producing working
software. Through constant communication and collaboration with the customer the course of the project can be

S. de Koning; MSc Thesis Software Project Management Page 8


August 15, 2011
changed during the project. This should then result in a closer fit between customer needs and the actual final
product. Much of the knowledge gathered in these agile projects is not being documented but is present as tacit
knowledge available in the group of people working on the project. This reduces overhead and results in more time
available for the actual creation of the product (Boehm & Turner, 2004).
Obviously the agile approach also has some disadvantages. The need for close customer collaboration
cannot always be fulfilled since the customer also has other duties and responsibilities. It is possible that the client
cannot be represented by only one person which can impede the collaboration. Agile methods usually need high
quality, highly motivated project members. Unfortunately these are not always available. It is not believed that agile
can be adopted in organizational cultures that are very formal and bureaucratic. There is also some skepticism about
the suitability of agile methods for large projects. Furthermore, it seems to be difficult to specify in a contract what
will be done since this is obviously only known on a very high level and can change drastically during the
development project. Clearly, both approaches have their advantages and disadvantages (Boehm & R. Turner,
2004a; Sommerville, 2007)
This is why Boehm and Turner (2004) propose combining agile and plan-driven methods into hybrid
methods. This way one can tailor and combine the methods in order to receive maximum benefit from both methods.
The opinions in the agile and plan-driven worlds about whether to completely use an approach or combine /
use the parts one sees appropriate is divided (Boehm & Turner, 2004). The approaches discussed in this chapter will
be considered as the pure forms of these approaches. Only the approaches that have been important in the evolution
of software project management methods and approaches relevant to this thesis will be discussed.

2.2 Plan-driven approaches


2.2.1 The waterfall model
In 1970 Dr. Winston W. Royce introduced the waterfall model. He distinguishes two steps that are essential:
analysis and coding. These steps are in his opinion the only steps the customer would like to pay for while the other
steps are necessary but not wanted. When developing larger systems however, additional steps are necessary and
unavoidable. He in fact already points out that a software development method would ideally only contain analysis
and coding which has a remarkable resemblance with agile thoughts.
Figure 2 displays the complete model from his research paper (Royce, 1970). It includes seven steps
starting with “system requirements” and ending with “operations”. In each step one can get back to the previous step
of move forward to the next step. Linking further away than one step is not intended. While Royce permits stepping
back and forward, the waterfall model is generally known as having separate steps among which cannot be switched.
Each step involves certain documents which have to be “signed off” before proceeding to the next step. A project
cannot be operating two steps at the same time. In practice however there seems to be some overlap and information
exchange. These iterations however involve significant rework and are therefore costly. It is therefore normal to
freeze certain parts of the process. Royce also indicates that the waterfall should be followed twice since the first run
will not deliver the desired final product but will function as a test run to determine what the real end product should
be. In practice however, the waterfall is only followed once (Royce, 1970; Sommerville, 2007).
The waterfall model uses a lot of documentation which enables new project members to join the project
group with less introduction problems (Sommerville, 2007) which is an advantage. There are also several
disadvantages when using the waterfall model. Returning to a previous step involves significant rework and results
in high costs. Going back several steps involves major rework and is therefore very unattractive. Changing
requirements is therefore a big problem when using this method. This may result in a system that does not answer to
the customer‟s need. This method should therefore only be used when the requirements are stable and known in
order to avoid problems (Sommerville, 2007).

S. de Koning; MSc Thesis Software Project Management Page 9


August 15, 2011

Figure 2: The waterfall model. Source: (Royce, 1970)


2.2.2 Spiral model of the software process
Instead of considering the software development process as a sequence of activities, Boehm‟s spiral software
development process model (Boehm, 1988) is represented as a spiral (Sommerville, 2007). The four quadrants
represent phases which every loop goes through. The four phases are “Objective setting”, “Risk assessment and
reduction”, “Development and validation” and “Planning” (Sommerville, 2007). The spiral model explicitly covers
risk where other software process models do not do this as explicitly (Sommerville, 2007).
The spiral model can be seen as the next step in the evolution of software project management methods since it
contains loops and repeatedly covers the same four phases but is still based on the waterfall approach.

2.2.3 PRINCE2
PRINCE2 was introduced in 1997 as the successor of PRINCE (PRojects IN Controlled Environments) which was
developed by the British Office of Government Commerce. While PRINCE was mainly focused on ICT-projects,
PRINCE2 was meant to be a more general software project management method. PRINCE2 consists of several
standardized processes (figure 3) with pre-specified roles and documents and can be classified as a plan-driven
method (Office of Government Commerce, 2009; Onna & Koning, 2010). As can be seen in figure 3, the processes
follow after each other and the different steps could be compared to those in the basic waterfall method.

Key: SU = Starting Up a project, IP = Initiating a Project, SB = Managing a Stage Boundary, CP = Closing a Project
Figure 3: The PRINCE2 processes. Source: (Office of Government Commerce, 2009)

S. de Koning; MSc Thesis Software Project Management Page 10


August 15, 2011
The latest version of PRINCE2 is believed to be more flexible in order to enable the integration of agile software
project management methods. One of the seven principles described in the latest version is “tailor to suit the project
environment” (Office of Government Commerce, 2009). This is also described in chapter 19 of the latest Prince2
manual. Prince2 is therefore a modern plan-driven approach using a waterfall model but is leaving an option for the
software project manager to tailor the method and even introduce agile components

2.2.4 More plan-driven software project management methods.


Several adaptations of the waterfall model like SSADM (Structured Systems Analysis and Design
Method)(Ashworth, 1988), SDM (System Development Methodology)(W. S. Turner, 1987), several US military
standards like Mil-Std-498(Moore & Rada, 1996) and their follow-ups like IEEE standard 12207(IEEE, 2011) have
been designed through the years to manage software projects. Other supporting concepts like SW-CMM (Software
Engineering Institute, 2011a) and CMMI (Software Engineering Institute, 2011b) have been designed to support the
formal processes. Each have their own characteristics, pros and cons but these will not be discussed in this thesis
since they are less relevant for this research.

2.3 Agile approaches


2.3.1 XP
In 1999 the term Extreme Programming (XP) was coined by Kent Beck. This agile development method was called
XP because it applied certain old development principles and practices to the extreme. XP puts all these practices
under one umbrella (Kent Beck, 1999a, 1999b; Sommerville, 2007). XP is one of the first and most well-known
agile approaches.
XP uses Cost, Time, Quality andScope as the four main variables. The customer can decide on three of
them while the project team will then decide on the fourth (Beck, 1999b). XP also has four core values:
Communication,Simplicity, Feedback and Courage which are very important in an XP-project (Beck, 1999b). The
most important principles in XP are: Rapid feedback, Assume simplicity, Incremental change, Embracing change
and Quality work (Beck, 1999b). This means using incremental development using small user stories, continuous
testing, involving the customer and optimizing the communication process and code quality by using pair
programming and other practices. Scaling with XP is an issue; a team should not consist of more than 20 people.
Long feedback cycles and dispersed teams are barriers to success for XP (Boehm & Turner, 2004). XP relies on the
on-site customer who is often busy. Furthermore, when the system is complex it can be difficult to remember
everything and the planning perspective can be too short to grasp the big picture (Nawrocki et al., 2006).

2.3.2 SCRUM
Scrum is an agile software project management method which uses several different roles, meetings and products to
manage the software development in an agile way. Scrum uses several roles and concepts which will now be
explained (Schwaber, 1997; Schwaber & Beedle, 2002).
The foundation of the project is the product backlog which is maintained and filled by the product owner.
The product owner filters the desires from the company and describes and prioritizes the features on the product
backlog. The project team will then, with the help of the Scrum master who supports the team, produce small
working increments every one to four weeks (sprint). After every sprint the increment is being reviewed and new
features are to be selected for the next sprint. During the project the project team uses several tools like burn down
charts and the sprint backlog. A graphical representation of the Scrum method can be seen in figure 4. It is also
considered very plausible to combine Scrum and XP where Scrum is the management approach and XP is the
development (programming) approach (Kniberg, 2007; Schwaber & Beedle, 2002).

S. de Koning; MSc Thesis Software Project Management Page 11


August 15, 2011

Figure 4: Scrum Source: Adapted from (Deemer, G. Benefield, Larman, & Vodde, 2010; Schwaber, 2004)

Scrum can be introduced in a company without disturbing the traditional environment too much. By using Scrum
just for one project in a company, the company can test the effectiveness of the method and thus judge about a
further implementation of Scrum in the company. With Scrum, it is possible to scale up for larger projects which is a
benefit (Schwaber & Beedle, 2002). It is hard to use Scrum entirely when the project is not very important and
priority is low. One then easily returns to old methods (Highsmith, 2002). The role of product owner also makes
Scrum more difficult to apply since the company should provide a product owner fulltime that has power,
knowledge and authority and sticks to the project while there are other people needing him as well. As with almost
all agile methodologies, Scrum also demands high quality team members while they sometimes may not be available
for the project. This can make it more difficult. Furthermore, it can be very hard to prioritize the different features
since every stakeholder perceives the priority of their feature as high. It is the task of the product owner to deal with
this (Sommerville, 2007). This is however also a problem with plan-driven approaches. Where XP is more an agile
development approach, Scrum is more an agile software project management approach having different project
management tools and providing clear roles and concepts.

2.3.7 Lean Software Development


Lean Software Development was first developed by Robert Charette. His vision of Lean development involves
starting with the top of the organization. Lean Development is, according to Charette “the creation of change-
tolerant software with one-third the human effort, one-third the development hours, one-third the time, one-third the
investment in tools and methods, and one-third the effort to adapt to a new market environment” (Highsmith, 2002).
His version of Lean development encompasses four critical success factors and twelve principles which correspond
with general agile principles. Although Charette‟s version of Lean development is popular in practice, there has
been little scientific documentation about his method.
Lean Software Development was also described by M. and T. Poppendieck in their book “Lean Software
Development An Agile Toolkit” (2003) and was, like Charette‟s version, based on the Lean thinking principle
developed by Toyota in the late 1940s. The basic principle behind Lean thinking is „eliminating waste‟. Waste,
according to Lean thinking, is everything that does not create value for the customer. The seven wastes are:
Inventory, Extra processing, Overproduction, Transportation, Waiting, Motion and Defects (Shingo, 1989). These
should be eliminated / reduced as much as possible.
Lean Software development is based on these seven wastes although the wastes have been translated to the
software engineering field. The seven wastes of software development are: Partially Done Work, Extra Processes,
Extra Features, Task Switching, Waiting, Motion and Defects (Poppendieck & Poppendieck, 2003). In order to
eliminate these wastes, M. Poppendieck and T. Poppendieck developed 22 thinking tools that will aid software
development leaders in their task of becoming more agile in their companies (Poppendieck & Poppendieck, 2003).
While the origins of XP and Scrum lie in software development, the origins of lean software development lie in
production. Where XP is more an agile development method and Scrum is more an agile software project

S. de Koning; MSc Thesis Software Project Management Page 12


August 15, 2011
management method, Lean software development is an agile mindset like Lean thinking was for the production
environment.

2.3.8 More agile software project management methods


Other well-known agile software project management methods are for example Adaptive Software Development ,
several versions of Crystal (Cockburn, 2006; Highsmith, 2002), Feature Driven Development , Kanban (Middleton
& Joyce, 2011; S. R. Palmer & Felsing, 2002) and the Dynamic Systems Development Method (Stapleton, 1997) .
These methods all vary in their approaches, origins and levels of agility. Although these are interesting, they are less
relevant for this thesis and will therefore not explicitly be discussed.

2.4 Hybrid approaches


2.4.1 RUP
The Rational Unified Process (RUP) is a modern software project management method that is considered to be a
hybrid method (Sommerville, 2007). Although RUP has generally been viewed as a plan-driven approach due to the
large volume of guidelines, many of the agile attributes are incorporated in RUP like using iterations (Boehm &
Turner, 2004). RUP consists of four phases which each individually can iterate but it is also possible to use iterations
for the entire process. The first phase is the inception phase in which a business case is developed to assess the
relevance of the project. The second phase is the elaboration phase in which a general understanding of the project is
developed, an architectural framework is developed along with a project plan including requirements and risks. The
third phase is the construction phase in which system design, programming and testing is being done to deliver a
working product along with the associated documentation. The fourth phase is the transition phase in which the
product is moved from the development community to the user community which means it is put in the real
environment (Sommerville, 2007). While RUP uses iterative development, it also maps requirements before the
actual development in the elaboration phase, often using UML models which is not very agile. Several
recommended best practices also limit the agility of RUP like having change management systems and defining and
visualizing the requirements before developing the software (Sommerville, 2007). RUP can therefore be considered
as a hybrid method positioned a little bit more to the plan-driven side than to the agile side on the planning
spectrum.
RUP was first developed by Rational Software and was later taken over by IBM (IBM, 2011) where they still
promote it and accompany it with an electronic tool.

2.4.2 Scrum, Lean Software Development and CMMI


Sutherland, Jakobsen and Johnson (2008) combined CMMI, Lean software development and Scrum. They study a
company which is CMMI Level 5 compliant. By adapting the Lean Software Development mindset and introducing
Scrum they successfully managed to combine these approaches in one software project management method which
enabled “significant gains in productivity and quality over traditional methods” (Sutherland et al., 2008). Besides
this, they claim to be delivering more value to the customer since they respond to the real needs of the customer.
They conclude with advising companies to fit agile methods in their CMMI frameworks (at least CMMI level 3).
There is however only little real information given in the paper which limits the possibility to judge this hybrid
software project management method‟s pros and cons.

2.4.3 ISO 12207, XP, Adaptive Software Development and Scrum.


Oliveira Basto da Silva and Rupino da Cunha (2006) studied an organization that developed software for the space
industry. Getting more involved in the industrial sector however, the organization encountered several problems:
changing requirements, lack of customer involvement, tight deadlines, low budgets and frequent miscommunication.
With no possibility to avoid various quality certifications needed to play in selected markets, the company sought to
become more agile to cope with the problems. They combined the already existing process with parts from XP,
Adaptive Software Development and Scrum which resulted in a hybrid software project management method which
seems quite formal but uses several agile components.
The method seemed quite successful according to the writer and is “simultaneously, agile enough to deal with
unstable requirements and formal enough to meet quality certifications” (Oliveira Basto da Silva & Rupino da

S. de Koning; MSc Thesis Software Project Management Page 13


August 15, 2011
Cunha, 2006).The paper however provides only limited information and the pros and cons of this hybrid software
project management method can therefore not be properly assessed.

2.4.4 XPrince (XP, Prince2 and RUP)


Nawrocki, Olek, Jasinski, Paliswiat, Walter, Pietrzak and Godek (2006) studied a case where XP, Prince2 and RUP
were combined into XPrince (eXtreme PRogramming IN Controlled Environments). This resulted in an “integrated
and flexible software development methodology… along with accompanying tools which aims at balancing agility
and discipline”. The aim of the developers was to solve the problems with XP‟s weaknesses and still preserve
agility. To do this they integrated a project management methodology (Prince2) with a development methodology
(XP) resulting in XPrince (Nawrocki et al., 2006). The developers combined and translated several different roles
from Prince2 and XP. They also constructed a project lifecycle combining Prince2, RUP and XP. The authors
conclude by saying that the method has been used in practice in a commercial project but fail to state and explain
success and if the method solved the problems they indicated in their introduction. This paper therefore also contains
only little useful information to assess the method and its pros and cons to compare with the other methods.

2.4.5 More examples


There are some more examples in literature of hybrid software project management approaches like Code Science
(Manzo, 2002) and from product development for example combining an agile approach with Cooper‟s stage-gate
model (Karlström & Runeson, 2006) but in general, literature about hybrid software project management approaches
is hard to find. This seems strange because in practice a lot of organizations seem to use a hybrid approach. Because
of the limited information that was found, it was also very difficult to compare the hybrid approaches.

S. de Koning; MSc Thesis Software Project Management Page 14


August 15, 2011

3. Research method
Chapter 3 will discuss the research method used in this thesis. Paragraph 3.1 will introduce and motivate the
choice for the case study method after which paragraph 3.2 is about developing the theory, paragraph 3.3
about the case selection, paragraph 3.4 about the data collection and paragraph 3.5 about how the findings
were processed.

3.1 Case study method.


For this research the qualitative (interpretative) research approach was used. This research studies four cases in order
to test the five propositions mentioned in chapter 1 and give an answer to the main research question. This will be
done by illuminating the decisions that led to the choice for a specific combination and application of software
project management methods, how this method was used en what the result was (Yin, 2009). This fits the definition
of the case study method as has been used in this research. The findings have not been based on statistical
procedures but have been based on carefully studying the four cases from different perspectives and using different
sources of evidence (Strauss & Corbin, 1998; Yin, 2009). This will result in a good internal validity but will result in
a lower external validity which will also be discussed in chapter six.
The foundation of the research method is the case study research method as described by Yin (2009). This
method will be adopted during this research as the research template. It consists of several phases which will all be
discussed in the following paragraphs.

3.2 Developing the theory.


3.2.1 Background literature
A case study starts with defining and designing the study. This phase covers a background literature study (chapter
2) to become more knowledgeable about the subject as suggested by Yin (Yin, 2009). In this case this meant
studying different software project management methods and underlying theories.

3.2.2 Research framework


Based on the background literature study a research framework was developed which is the foundation for
this research. The framework encompasses two main topics: General project information and the Position on the
planning spectrum. The first topic has two dimensions, namely general project result and software project
management. The second topic has five dimensions, size, criticality, culture, dynamism and personnel (figure 5).
These have been derived from Boehm and Turner (2003a & 2004). These are also the main variables in propositions
one to five which are expected to influence the project success and the software project management method.
The dimensions can be divided into different factors which will help to form a judgment about the
dimensions. Several factors have been derived from Boehm and Turner‟s research like dynamism, the complexity
scale and the Cockburn skill levels. Other factors have been gathered from other scientific papers based on their
possible relevance for the different dimensions like Greiner‟s model, trust levels and the organization type. Together
these factors were aimed to be the most influential factors for the different dimensions although the list of factors is
certainly not exhaustive.
The research framework in figure 5 contains these factors, dimensions and their significance and influence.
The first column contains the seven dimensions that have been studied. The second column contains the
corresponding factors. The third column contains several boxes with a question mark in it. Depending on the results
from this research these boxes will be filled with the following answers: If the factor is significant and if the factor
has a positive or negative influence on the amount of plan-driven components. The fourth column contains the two
main topics. The questions marks in this research framework will be answered in chapter 5.
The seven dimensions and factors per dimension will now be discussed:
General project result
To form a judgment about the general project result it is necessary to know if the project was successful and how the
performance was considering the different performance indicators. This dimension will therefore cover determining
project success using indicators like time, budget and satisfaction.

S. de Koning; MSc Thesis Software Project Management Page 15


August 15, 2011

Dimensions Factors Significant influence? Main topic


1.1 Time
1. General Project
1.2 Budget
Result General
1.3 Satisfaction
Project
2.1 Software Project
2. Software Project Management Method
Information
Management
2.2 Satisfaction

Dimensions and factors influencing the position on the planning spectrum.


3.1 Application size (SLOC) ..?
3.2 Man-hours ..?

3. Size 3.3 Project type ..?


3.4 Team size ..?
3.5 Complexity ..?

4.1 Loss Scale ..?


4. Criticality
4.2 Time constraint ..?

5.1 Organization type ..?


5.2 Company growth stage ..?
Position on the
5. Culture planning
5.3 Trust ..?
spectrum
5.4 Organizational culture ..?

6. Dynamism 6.1 Cockburn dynamism scale ..? Agile à Plan-


driven
7.1 Extended Cockburn method
..?
skill rating scale

7.2 Experience ..?


7.3 Education ..?
7. Personnel 7.4 Project manager type ..?
7.5 CRACK Customer ..?

7.6 Project personnel turnover ..?


7.7 Familiarity with the
..?
technology

Figure 5: Research framework Source: Own research

Software project management


This dimension discusses the software project management method that was used in the cases and how it was
perceived by the customer and the developer.
Size
Boehm and Turner state that smaller teams and projects are the home ground for agile methods while larger teams
and projects are the home ground of plan-driven methods (Boehm & Turner, 2003a; 2004). This dimension has
therefore been considered for the cases studied in this thesis. The application size would have been determined by
calculating the number of function points using a gearing factor from a Source Lines Of Code (SLOC) analysis.
Unfortunately it was not possible to collect the proper data to do a correct analysis. The influence of this factor has
however still been studied. From contracts and bills the amount of man-hours spent on the project has been derived
and discussing the project with project participants has provided information about the project type and the team size
during the project. Project participants were also asked to rank the project according to the complexity scale
discussed by Ken Schwaber (Schwaber, 2004) where the vertical axis represents the requirements complexity and
the horizontal axis represents the technology complexity.

S. de Koning; MSc Thesis Software Project Management Page 16


August 15, 2011

Criticality
The factor criticality is about the impact of the failure of a project. The loss scale (Cockburn, 2006) has been used to
determine the criticality of the project. It encompasses four categories varying from small impact to large impact:
Loss of Comfort, Loss of discretionary monies, Loss of essential monies and Loss of life. Apart from the loss scale,
the time constraint on the project has been studied since this can also put more pressure on the project and the
project participants.
Culture
Boehm and Turner state that agile methods are more suited for cultures that thrive on chaos and plan-driven methods
are more suited for cultures that thrive on order. Several factors have been examined concerning culture. Collins‟
good-to-great matrix (Boehm & Turner, 2004) has been used to rank the customers‟ organization on two axes; ethic
of entrepreneurship (agility) and culture of discipline. The company growth stage according to Greiner (Greiner,
1972) has been determined for the different organizations ranking them in one of the stages of growth or crsis. The
trust between the customer and the developer has been judged using the trust degrees developed by Abdul-Rahman
and Hailes (1997). The culture has also been categorized according to the four basic organizational cultures defined
by Moore (Highsmith, 2002) which are cultivation, competence, collaboration and control.
Dynamism
Dynamism is about the rate of change in a project. Agile methods are believed by Boehm and Turner to be suitable
for every rate of change while plan-driven methods are only suitable for low rates of change. In order to rate the
dynamism, the Cockburn dynamism scale (Cockburn et al., 2002) has been used. This scale varies from relatively
stable via varying to wildly fluctuating.
Personnel
The quality of personnel is very important for project success. Boehm and Turner state that while plan-driven
methods may work well with both high and low skill levels, agile methods require relatively higher skill levels. In
order to be able to judge the project personnel, several factors have been used. The extended Cockburn method skill
rating scale (Boehm & Turner, 2003a) has been used to determine and compare the skill levels of personnel.
Furthermore, questions have been asked about experience, education and the project manager type. The project
manager type will be categorized using Lewin‟s types: laissez faire, democratic, autocratic and bureaucratic (K
Lewin, Lippitt, & White, 1939; Kurt Lewin, 1944). The customer involved with the project will also be judged
according to the CRACK definition (Boehm & Turner, 2003a) where the customer should be collaborative,
representative, authorized, committed and knowledgeable in order to run a successful project. Project personnel
turnover is also investigated to determine if a high or low turnover has a negative, positive or no influence on project
success. Finally the familiarity with the technology will be discussed to determine if this has an influence.

3.3 Selecting the cases.


This study concentrates on four cases which have been selected based on their application of software project
management methods and possibilities for gathering information and data about these cases. One case was managed
using an agile method while the other three cases were managed using a hybrid method varying in the amount of
plan-driven components. This way the cases can be compared on the different dimensions/factors that will be
studied and a judgment can be made about the influence of the different factors on the position on the planning
spectrum of a project. In each case, two or three of the leading project members (project manager, product owner or
lead members) were selected for interviews.

3.4 Data collection


To gather information and data about the cases, several different resources have been used in order to apply
triangulation (Yin, 2009). Triangulation is about using multiple sources of evidence to come to findings. Several
information gathering techniques and sources have been used. Using these different sources to come to conclusions
is one of the strong aspects of a case study since this is more in depth than just one source of evidence. For the case
studies, the following sources of information were used:
 Project documentation

S. de Koning; MSc Thesis Software Project Management Page 17


August 15, 2011
 Contracts
 Open-ended interviews
 Semi-structured interviews
 Promotional material (Whitehorses in Business, videos)
 Semi-promotional material (Whitebooks)
 Hour-registration records
 The applications created during the project.
 Company websites
It should be noted that, because of the nature of agile methodologies, it was hard to collect data about the projects
from project documentation and such since agile promotes having less documentation. A lot of the information was
therefore acquired during the interviews with representatives from both the customer and the developer to provide
two contrasting perspectives. Together, these different sources of evidence were a good foundation on which to base
the findings in this thesis.
The interviews have been based on the research framework, covering every factor to determine its significance for
the projects that have been studied and for future projects. The interview layout can be found in appendix A. Several
ordinal scales were used to be able to compare results among interviewees and cases. Literature about formulating
interview questions has been used to formulate objective questions (F. J. Fowler, 1995; Oppenheim, 1992). The
interviewees were all project managers, leading project members or product owners / customer representatives to
ensure a more high-level view of the projects.

3.5 Processing case findings


The case findings were summarized per case in chapter four. The different factors are discussed there per dimension
to determine if they had an influence on the position on the planning spectrum of the software project management
method in the case or if they would have an influence on this in future projects. A mean value was determined for
factors where the different interviewees or sources provided different values.
In chapter 5 the results from the individual cases were combined to present cross-case conclusions about
the different factors and dimensions and their relevance in the choice of the software project management method.
Factors were judged significant using triangulation. Factors were only judged to be significant or not significant
when this was supported by all four cases based on the data and information gathered in these cases. For several
factors the data and information across the four cases did not provide enough confidence about the significance of
these factors since there were contrasting values. The significance of these factors was therefore judged as
inconclusive.
All the factors were processed in the final framework which can be found in the conclusion of chapter 5.
This framework visualizes all the factors and dimensions with a clear overview if the factors were found to be
significant and how these factors influence the position on the planning spectrum of a software project management
method.
The conclusions from chapter 5 were then processed in chapter 6 where the discussion covers the answers
to the propositions based on the findings and answers the research question. Chapter 6 also discusses the
contribution to research and practice including advice for researchers, software project managers, developer
organizations and client organizations. Chapter 6 is concluded with some recommendations and the limitations of
this research.

S. de Koning; MSc Thesis Software Project Management Page 18


August 15, 2011

4. The cases
Chapter 4 will discuss the findings for the four cases in paragraphs 4.2 to 4.5 after a short introduction in
paragraph 4.1.

4.1 Introduction
This chapter will discuss the four individual cases that have been studied. Every paragraph will first introduce the
case. The software project management method used in the case will then be discussed followed by the project result
and the findings on each of the five dimensions mentioned in the propositions that have been based on Boehm and
Turner (2004).
Every subparagraph starts with a table summarizing the outcome for every factor. The complete ordinal
scales can be found in appendix C. For some factors a value is represented like for example 4/5. This means that the
fourth value of the five-value scale was chosen for this factor. This number is always accompanied by the
corresponding description. The tables are accompanied with text summarizing how and when the factors have
influenced the choice of the application of the software project management method.

4.2 Case A
4.2.1 Case introduction
This case is about a project that was conducted for one of the important student bureaus in the Netherlands which is
the link between the student and the bureau where every student should register for receiving student grants and
registering as a student in the Netherlands. The organization was started in 2005 and evolved from another
organization. The organization has seven employees. The product that was developed was a stub that would test the
connection between the two student bureaus and simulate message exchange.

4.2.2 Software project management method


Factor Outcome
Position on planning spectrum Agile---Plan-driven 1/10 Agile
Satisfaction with software project management method 4/5 Satisfied
Added amount of plan-driven components Appropriate
Scrum was used for this project. Using Scrum resulted in a finished product within two months. A so called Sprint 0
was added. This sprint was meant to determine several basic things like if it can be done, which language/tool was to
be used and such. All the basic Scrum practices were applied in this project. Figure 6 displays a graphical
representation of the agile software project management method used.

Figure 6: Software Project Management Method Case A Source: Own research

The project team was satisfied with the choice of the software project management method. Because of the high
volatility of the requirements and the lack of a well-defined architecture it was the most suitable approach. Since it
was unclear at the start of the project what exactly was going to be produced, having short iterations of two weeks

S. de Koning; MSc Thesis Software Project Management Page 19


August 15, 2011
helped control the budget. These short iterations resulted in a “rush feeling” for both the customer and the developer
since functionality was produced very fast and interaction between customer and developer was intensive. The
developer does indicate that having less capable people on this project would have made it more difficult to
successfully complete the project.
No plan-driven components were added in this project and the project team indicated that they were very
satisfied with this approach. Plan-driven components were not required in this project. The necessary documentation
that was completed with the application was only one file of 215 KB which is only 0.6 percent of the total end
product size of 33.6 MB.

4.2.3 Project result


Factor Outcome
Completed on time? 5/5 Completed before deadline.
Completed within budget? 5/5 Yes, we finished with some budget left.
Customer satisfied? 4/5 Satisfied
Developer satisfied? 5/5 Very satisfied
As can be seen in the table, the project was quite successful. It was completed on time, within budget and everybody
was satisfied with the result. It can therefore be concluded that this project was very successful.

4.2.4 Size
Factor Outcome
Project duration 2 Months
3.1 Application size (SLOC) 23602 Lines of Code
3.2 Man-hours 311,5 hours
3.3 Project type New application
3.4 Team Size 4 People
3.5 Complexity 4/5 Complex
In sprint one, 11 user stories were completed and in sprint two 24 user stories were completed and six unfinished
user stories were left. The project was completed within two months; it was therefore a relatively short project.
To determine the application size a Source Lines Of Code (SLOC) calculation was performed. The
application encompassed 23602 SLOC. It was however not possible to derive the amount of function points from
this to have a good indication of the size of the application. A large part of these lines of code were generated using
a graphical programming tool and a large part of the lines were created in markup languages. The developer also
indicated that this is not a metric that he would use to choose a software project management method.
In total 311,5 hours were spent of which 65,5 hours were spent on project management by the developer
(21% of the time), 231 hours were spent on developing (74% of the time) and 15 hours were spent by the
customer(5% of the time). This factor however did not influence the software project management method. The
developer would in future however, in case of a large project with a lot of man-hours consider adding plan-driven
components from for example Prince2. So then man-hours would be a significant factor.
The project in this case was to develop a new application. Requirements were relatively unknown thus
resulting in a good situation to use an agile software project management method. The type of project therefore
influenced the choice for a software project management method. With an existing product, requirements are
probably better known.
The project team consisted of four people. The team size did not influence the choice of the software
project management method but in cases where the team would consist of much more people, adding plan-driven
components would be necessary to ensure correct communication according to the developers. The project manager
indicated that a team size of 10 people would be the maximum if possible; else a lot more organization,
communication and staff would be necessary thus lowering productivity per person.
The project was complex both from a technical perspective as from the requirements perspective. This placed the
project very close to anarchy on the scale discussed by Ken Schwaber (Schwaber, 2004). Complexity was certainly
an important reason to choose an agile software project management method such as Scrum. The developer believes
that, the lower you rank on both axes, the more plan-driven your software project management method could be.

S. de Koning; MSc Thesis Software Project Management Page 20


August 15, 2011
Higher complexity is also a reason, according to the project manager, to get people with higher skill levels on your
team.

4.2.5 Criticality
Factor Outcome
4.1 Loss scale 1.5/4 Loss of comfort / discretionary monies
4.2 Time constraint 4/5 High
In this case criticality had no influence on the choice of the software project management method but in case of
more serious losses, the method should be more formal. Criticality is then a significant factor.
Because the time constraint was high for this project, the choice was made for an agile method. More time
would perhaps make a more formal plan-driven method suitable but the agile method would still be preferred.

4.2.6 Culture
Factor Outcome
5.1 Organization type Collins – Customer Between the four types.
5.1 Organization type Collins – Developer Toward great organization
5.1 Organization type Collins – Project Team Great organization
5.2 Greiner‟s growth stage 5/10 Delegation phase
5.3 Trust 5/6 Good
5.4 Organizational culture Moore – Customer Control culture Competence culture
5.4 Organizational culture Moore – Developer Competence culture Collaboration culture
5.4 Organizational culture Moore – Project Team Collaboration culture
The organization types of the project team, the developer and the customer are all placed in the „great organization‟
quarter of the organization type figure by Collins (Boehm & Turner, 2004). This was perceived as an important
reason to choose for an agile method. This would probably not have been possible in a more bureaucratic
organizational culture. This factor would also influence the decision for the application of a software project
management method in future projects since more bureaucratic organizations would need a more plan-driven
approach while a great organization is perfectly capable of using an agile software project management method.
The customer was ranked in the delegation phase of the Greiner model (Greiner, 1972) which is quite high
considering the age and size of the organization. This can be explained by the fact that the customer organization
originated from another organization. Although it was no factor in the choice for the software project management
method, the developer thinks companies in the first three phases are very suitable and open to agile methods. The
last phase could again be open for agile methods but companies in this phase are considered to have figured out for
themselves what they want to use and the developer can only comply to their wishes. This factor could therefore be
relevant in the choice for a software project management method.
There was a good level of trust between the developer and the customer. The trust level was ranked at
good. This was very important for the agile method to succeed. It is however very difficult to determine the trust
level before the start of the project. If the trust level is therefore known, it should be considered a factor. This is
however not often the case. It is also possible to increase trust using an agile software project management method.
An agile method will produce results very quickly and is also based on a lot of interaction with the customer. This
could possibly result in gaining trust faster.
When ranking the organizational cultures using the four basic organizational cultures: cultivation,
competence, collaboration, and control from Moore (2000), the customer culture ranks as a control / competence
culture, the developer‟s culture as a competence / collaboration culture and the project team culture as a
collaboration culture. Although the developer clearly states that „culture is your biggest enemy when talking about
doing software projects‟, they did not use these four types in their choice nor would they use them.

4.2.7 Dynamism
Factor Outcome
6.1 Cockburn dynamism scale 2/3 Varying
This project had a varying rate of change since the requirements were not know at the start of the project and kept
changing. In total 41 user stories were described and planned during the entire runtime of the project of which 35

S. de Koning; MSc Thesis Software Project Management Page 21


August 15, 2011
were completed. This supports the varying rate of change since eventually 85 percent of the stories were completed.
This certainly influenced the choice for a software project management method. The agile approach is very suitable
for these kinds of situations while a plan-driven approach would be inefficient for projects with varying or wildly
fluctuating requirements according to the developers.

4.2.8 Personnel
Factor Outcome
7.1 Extended Cockburn method skill rating scale Level 2 / Level 3
7.2 Experience – Software development 8 to 20 years
7.2 Experience – Agile methodologies 4 to 15 years
7.3 Education Practical university +
7.4 Project manager type Democratic
7.5 CRACK customer 5/5 Yes
7.6 Project personnel turnover None
7.7 Familiarity with technology Little
The team members were new to Scrum, new to the programming language and requirements were very volatile.
They managed to transform these difficult starting conditions into a successful project. They can therefore be
categorized as level 2 or level 3 project members which is quite high. The highly-skilled project members were
essential for the project to succeed and for the agile method to work. According to the developer, in each scenario a
project member should at least be level 1A to be able to work on agile projects. In the future, the developer would
also introduce a 1A level (or higher) junior project member. This would possibly increase communication and bring
better balance to the group.
All team members have more than 8 years of experience in the field of software development (some
considerably more) and 4 to 15 years of experience with agile methodologies. They all also have finished practical
university at least. This also somewhat reflects their skill levels of which experience is most important, also for this
project. These factors should however, according to the developer, not be used in the choice for a software project
management method since these hardly say anything about a person‟s real skill level and personality.
The project leader‟s management style was identified as democratic. The developer emphasizes that this is
necessary since the agile approach is all about working together. This would therefore certainly be a factor in
choosing a software project management method unless the project manager would be selected after the software
project management method.
The customer in this case was collaborative, representative, authorized, committed and knowledgeable
(CRACK) as advised by Boehm and Turner (2003). This is however very difficult to judge upfront so this factor was
not used when considering a software project management method. A CRACK customer is however essential for the
success of an agile project. This would therefore be a factor in choosing the application of a software project
management method if known before the start of the project.
The team composition did not change during the project. This is important for an agile project to succeed.
The team was not very familiar with the technology but this was no factor for the choice of the software project
management method and will not be in the future.

4.3 Case B
4.3.1 Case introduction
Case B was the creation of an eService portal for a large international document solutions provider. In the BeNeLux
more than 30.000 customers contact the organization in this case to report malfunctions, provide usage information
and arrange service arrangements. A call center used to handle these contacts but increasingly customers wanted to
contact the company via a web-based self-service portal. This was the application that was built and integrated in the
project. The project was to be completed by the developer within three months with a fixed budget while the
customer had prepared the project. The customer organization was founded in 1982 and consists of around 1400
employees.

S. de Koning; MSc Thesis Software Project Management Page 22


August 15, 2011
4.3.2 Software project management method
Factor Outcome
Position on planning spectrum Agile---Plan-driven 4/10 More agile than plan-driven
Satisfaction with software project management method 4/5 Satisfied
Added amount of plan-driven components Appropriate
For this project, the developer used a simplified version of Scrum to manage the product delivery in an agile and
lean way. The developer identified using Scrum as an important factor for the success of the project. Scrum allowed
the developer to quickly react to changes and call in additional help for small practical problems while this would be
more difficult when not working agile. The developer was very pleased with the Scrum method.
For the overall project management and communication to the director, the customer‟s project manager used only
some parts of an adapted form of Prince2, called TOPAZ. This software project management method was the
standard approach within the customer company and had to be used. The overall project structure looked much like
a waterfall approach. A graphical representation of the software project management method can be found in figure
7. As can be seen only the “starting up a project” (business case) and the “directing a project” (communication with
management) components were used. The other components of the Topaz method were not used since these were
not essential according to the project manager. The project manager did produce a Microsoft Excel prototype before
contacting the developer and this was used to explain the main functionalities to the developer. The “Scrum Light”
components were then used by the developer in delivering the product.
Subsequent Delivery
Pre-Project Initiation Stage Stage(s)
Final Delivery Stage

Directing a Project
Directing
Starting Up
a Project.

Managing

Scrum Scrum
Delivering Prototype Light Light

Figure 7: Software Project Management Method case B Source: Own research


The documentation that was completed with the application were 13 files which in total were 4.22 MB. Compared to
the size of the final product (17.62 MB) this is a considerably larger part of the final product than in case A. This
certainly corresponds with the more plan-driven approach that was taken in this project. A part of this larger size
documentation can also be explained by the application being bi-lingual.

4.3.3 Project result


Factor Outcome
Completed on time? 4/5 Yes, exactly on time.
Completed within budget? 3/5 No, but less than 10% over budget
Customer satisfied? 4/5 Satisfied
Developer satisfied? 5/5 Very satisfied
The developer succeeded in developing the application the customer wanted within three months (exactly on time)
after a three months preparation by the customer and delivered a product that was more than anticipated upfront.
Because of the short iterations inherent to Scrum, the customer experienced that the developer listened very well and
was therefore able to translate this into a working product, every iteration. The project went over budget but no more
than 10 percent. Both the customer and the developer were very satisfied however so the budget overrun doesn‟t
seem to have been very serious.
4.3.4 Size
Factor Outcome
Project duration Six months
3.1 Application size (SLOC) Unknown
3.2 Man-hours 4500 hours
3.3 Project type Create a new product Integrate existing products

S. de Koning; MSc Thesis Software Project Management Page 23


August 15, 2011
3.4 Team Size 6 FTE divided among 3 fulltime and 12 part-time
3.5 Size - Complexity 3/5 Complicated
The project duration was six months which is somewhat longer than in case A.
The application size in Source Lines Of Code could not be retrieved. Application size is not considered as a factor in
considering a software project management method. A total of 4500 hours were spent on the project of which
around 1400 by the developer. The customer indicates that this could be a factor in the choice for a software project
management method. When considerably more hours are to be spent on a project within a short time period, one
should be more strict in using the TOPAZ method (plan-driven) to be able to manage the project properly.
The type of project did influence the choice for the software project management method according to the
developer. It was a new product which was easily dividable in smaller increments which was ideal for agile
development. The customer would not use the type of project in his choice for a software project management
method.
The team size did not influence the choice in this case because the method could just as easy be used with
just one person as with 9 persons at a time. A much larger team than this however would require a more plan-driven
method in order to be able to manage the project.
The project complexity was judged at complicated where the technology complexity was above average but
the requirements complexity was below average. The customer would use complexity in his consideration for the
application of a software project management method. The more complex a project gets the more the customer
would like to use a more plan-driven method.
4.3.5 Criticality
Factor Outcome
4.1 Loss scale 2/4 Loss of discretionary monies
4.2 Time constraint 4/5 High
The project failure would have resulted in the loss of discretionary monies according to the developer and the
customer. The customer believes that a lower loss level enables one to use a more agile approach.
The time constraint was high. This was however not a factor in the choice for a software project
management method.
4.3.6 Culture
Factor Outcome
5.1 Organization type Collins – Customer Great organization
5.1 Organization type Collins – Developer Great organization
5.1 Organization type Collins – Project team Great organization
5.2 Greiner‟s growth stage 5/10 Delegation phase
5.3 Trust 5/6 Good
5.4 Organizational culture Moore – Customer A little bit of everything.
5.4 Organizational culture Moore – Developer Competence culture
5.4 Organizational culture Moore – Project Team Collaboration culture
The customer, developer and the project team all were categorized as „great organizations‟ in Collin‟s “good-to-
great matrix”. This indirectly influenced the application of the software project management methods used in this
case as it will do in future projects. The customer believes that when the organization types are categorized in the
left two quadrants, a more formal, strict and plan-driven software project management method should be used.
The organization in this case is considered to be in the delegation phase of Greiner‟s model (Greiner,
1972). Considering the age and size of the organization one would possibly suspect the organization a little bit
further up the ladder but several mergers could have slowed this down. Overall the delegation phase seems to
correspond with the organization profile The customer believes that organizations in the more advanced stages will
need more plan-driven methods than organizations in the early stages.
The trust level in this case was always good which enabled more flexibility and agility. If there had been
less trust between the parties this would have resulted in a more formal software project management method. Trust
has therefore certainly been a factor in the consideration of the software project management method.

S. de Koning; MSc Thesis Software Project Management Page 24


August 15, 2011
The customer perceives organization culture as a very important factor in the choice for a software project
management method. The little bit of cultivation culture within the customer‟s organization enabled the start of this
project and also enabled the choice for this pragmatic combination of software project management methods. A
control culture is believed to need more plan-driven software project management methods.

4.3.7 Dynamism
Factor Outcome
6.1 Cockburn dynamism scale 2/3 Varying
The customer perceived the rate of change as „varying‟ and believes this fits well with the combination of software
project management methods that have been used in this project. A more stable project would probably use a more
formal (waterfall) method and a wildly fluctuating rate of change project would need a more agile method to
succeed.
4.3.8 Personnel
Factor Outcome
7.1 Extended Cockburn method skill rating scale Level 2 Developer, level 1B Customer
7.2 Experience – Software development 10 to 15 years
7.2 Experience – Agile methodologies 0 to 3 years
7.3 Education Practical university.
7.4 Project manager type Democratic Autocratic
7.5 CRACK customer 5/5 Yes
7.6 Project personnel turnover High
7.7 Familiarity with technology Medium
The developer‟s mean skill level was 2 and the customer‟s mean skill level was 1B. Because of the skill level of the
developer it was possible to use an agile approach in developing the product. A lower skill level would have resulted
in a more formal plan-driven method to ensure delivering the correct product with the right quality.
The experience of the members of the project team ranged between 10 to 15 years. The members from the
customer however had no experience with agile methodologies while the developer‟s members had several years of
experience with agile methodologies. Because the developer was familiar with an agile method, this method was
used. If there had been no experience with agile methods it would probably not have been used.
The average education level of the project members was practical university but this was and will be no
factor in choosing a software project management method. Skill can hardly be determined by education level
according to the customer.
The democratic leadership style of the project manager helped in applying the agile approach in this project
although he also made use of the autocratic style when necessary.
The customer in this case passed all five criteria of the CRACK customer. This was very important for the
project. Without a CRACK customer this project would have been more formally managed. There are however
doubts about how important a project is when the customer is not CRACK.
The team composition on the side of the developer changed frequently during the project apart from one or two
members. This was however no problem and did not influence the success of the software project management
method. Sometimes this even was a benefit because of the different skill sets of the project members.
The project team was relatively familiar with the technology used which made it easier to use a more
flexible, agile software project management method.

4.4 Case C
4.4.1 Case introduction
Case C studies a project at one of the large and well-known universities in the Netherlands with almost 20,000
students and employees and over 150 years old. The university eventually chose to use a Service Oriented
Architecture based on the Oracle SOA Suite. The larger goal of the university was to digitize their document flows.
This would enable the university to increase efficiency. Self-service is a part of this and this is where the project was
all about. The university aims at having a web portal with dynamic forms that is integrated with internal workflows.
This project was about enabling employees to reimburse their traveling expenses using a dynamic digital form and
managing the workflow accompanying this procedure. The developer used an existing backend product for this
S. de Koning; MSc Thesis Software Project Management Page 25
August 15, 2011
project which had to be expanded, developed a frontend for the university and had to integrate these products with
the existing products and workflows.

4.4.2 Software project management method


Factor Outcome
Position on planning spectrum Agile---Plan-driven 5/10 Agile + Plan driven
Satisfaction with software project management method 4/5 Satisfied
Added amount of plan-driven components Appropriate
The project was managed by the customer using Prince2. The “managing product delivery” phase was managed by
the developer using the Scrum approach as described in chapter 2. This can be seen in figure 8.
During the project, the developer‟s project manager experienced a lack of grip on the project and had to add
plan-driven components. A senior consultant from the developer was then involved to put the project on the right
track. By adding components from Prince2 like the Product Breakdown Structure, Planning, a list of issues and a
risk analysis to Scrum, the project could be continued with more control. This was necessary because of the different
organizational cultures, past experiences by the customer with their internal IT-department and continually changing
requirements. Scrum continued to be used in the developer‟s project team and this did result in timely delivering
components and transparency for the customer. This certainly had an influence on project success. In retrospective
however, the developer would have added components from Prince2 at the start of the project to start the project
with more certainty and control and would even have added more components like a more formal acceptance of
deliverables. Eventually both the customer and developer were satisfied with the software project management
method that was used. The software project management method certainly helped making the project a success.

Figure 8: Software Project Management Method Case C Source: Own research


While Prince2 provided a structure, a basis for communication with management and the steering committee and a
planning, Scrum provided the project with flexibility and decisiveness.
The documentation needed for the project was eventually 235 files and 47.9 MB large which is almost
three times the documentation needed for case B. This also supports the fact that this project was more plan-driven
considering the total man-hours were only twice as many as in case B.

4.4.3 Project result


Factor Outcome
Completed on time? 4/5 Yes, exactly on time.
Completed within budget? 3/5 No, but less than 10% over budget.
Customer satisfied? 5/5 Very satisfied
Developer satisfied? 4/5 Satisfied
Before the project, employees had to wait at least 30 days before they would receive a refund for their travel
expenses. After completion of the project, 97 percent of the refunds are received within four weeks. This resulted in
a reduction of the work load by two to three FTE‟s (Full Time Equivalent). The new application saved
approximately € 200.000,- and the project budget was € 130.000,- which means the project was earned back in less
than a year. Users also embraced the new application since 75 percent of the declarations were done using the new
application almost directly after the implementation.
The project was completed exactly on time and was almost completely within budget. The customer was
very satisfied and the developer was satisfied so the overall view of the project is that it was a success.

S. de Koning; MSc Thesis Software Project Management Page 26


August 15, 2011
4.4.4 Size
Factor Outcome
Project duration 23 Months
3.1 Application size (SLOC) Unknown
3.2 Man-hours 9135,5 hours
3.3 Project type New product Expansion of an existing product
3.4 Team Size 13 People
3.5 Size - Complexity 4/5 Complex
The project took 23 months from the first initiative to a fully working product. The developer was involved in the
project during the last 14 months.
The number of SLOC could not be determined. This is because the end-product was developed using
already existing applications and was integrated with other applications. Another factor is that the product was
developed using a graphical programming tool which generates lines of code. This makes it very unreliable to
measure the size of the application by counting lines of code. The application size did also not influence the choice
for the software project management method and the developer would not use it in a new project unless more SLOC
should mean more complexity, then a stricter application of the method would be applicable.
A total of 2535,5 hours were spent by the developer on this project divided among 10 project members
where four or five members were responsible for the majority of the hours. From the customer side a total of around
6600 hours were spent. The amount of man-hours needed for the project did not influence the choice for the
software project management method and, according to the developer, will also not influence a future choice unless
this can be linked to the project complexity.
The project in this case involved creating a new product (front-end), expanding an existing product (back-
end) and integrating the product with existing systems and processes. This mix of project types did however not
influence the choice of software project management method but the developer would use this factor in the future
for certain difficult projects to ensure more control.
The developer‟s team consisted of 4/5 members from the developer‟s company. Furthermore the customer
contributed a team with 8 team members plus a project manager from the customer. This resulted in a team size of
around 13 people. This did not influence the choice of the software project management method. In a future project
with several larger teams, the developer and the customer would apply the method more strictly but would not
necessarily choose another method.
When considering complexity, the project is ranked as a complex project. The complexity of the project did however
not influence the software project management method. In future projects however, the developer and the customer
would apply the software project management method more strictly if a project is more complex.

4.4.5 Criticality
Factor Outcome
4.1 Loss scale 2/4 Loss of discretionary monies
4.2 Time constraint 4/5 High
Project failure would have resulted in a loss of discretionary monies which indicated a considerable loss but one that
would not result in bankruptcy or loss of life. Project success would open doors for the implementation of a service
oriented architecture application that was essential for future IT-projects. In this case the criticality did not influence
the software project management method choice but in case of a „loss of essential monies‟ or a „loss of life‟ project
the developer would choose another, more plan-driven methodology like Prince2 which would help the developer in
managing risks. The customer would apply Prince2 more strictly.
The time constraint was high. This did not influence the choice for the software project management
method since the developer believes the time constraint is high in almost every project. This is also why the
developer would not consider this factor in future projects. The customer managed the project more strict and formal
because of the higher time constraint and would also do this in the future to get grip on the project and to ensure
meeting deadlines.

S. de Koning; MSc Thesis Software Project Management Page 27


August 15, 2011
4.4.6 Culture
Factor Outcome
5.1 Organization type Collins – Customer Bureaucratic organization Hierarchical organization
5.1 Organization type Collins – Developer Great organization Startup organization
5.1 Organization type Collins – Project team Great organization Startup organization
5.2 Greiner‟s growth stage 8/10 Red Tape Crisis
5.3 Trust 3/6 Minimal to 5/6 Good
5.4 Organizational culture Moore – Customer Control culture
5.4 Organizational culture Moore – Developer Collaboration culture
5.4 Organizational culture Moore – Project team Collaboration culture
The customer‟s organization type was ranked between the hierarchical and the bureaucratic organization in Collins‟
“good-to-great matrix” (Boehm & Turner, 2004). The developer‟s organization and the project team were
categorized as great organizations with a tendency toward the startup organization. This clearly results in a gap
between the organizations on the agility-axis. Initially this did not lead to another choice for the software project
management method but during the project this did influence the addition of Prince2 components to Scrum. The
customer was aware of its culture and therefore started with the Prince2 method. In a future project, the culture
should be determined and the software project management method should be more plan-driven when ranked in the
left half of the figure.
The developer and the customer indicate that, according to the Greiner model (Greiner, 1972), the customer
is in a „red tape crisis‟. The stage where the organization‟s formal methods are getting less efficient and effective.
Considering the size and age of the customer organization this seems to be a correct judgment. This did not
influence the choice for the software project management method but it is believed that a more mature organization
that has passed this crisis would be more suitable for agile software project management. An organization that is in
one of the earlier stages is probably also more suitable for agile methods.
During the project, the level of trust increased from minimal to good. The developer perceives this as a
normal process in projects and did not base the software project management method on this. The customer
perceives trust as an important factor where more trust enables more agility and less trust results in a more plan-
driven formal software project management method.
When ranking the organizations according to Moore‟s four organizational cultures (Highsmith, 2002), the
customer can be classified as a control culture which corresponds with the hierarchical / bureaucratic culture
mentioned earlier. The developer and the project team can be classified as collaboration cultures. The fact that the
project team and the developer had collaboration cultures enabled the use of an agile method. The fact that the
customer had a control culture made the more plan-driven method Prince2 necessary. This pattern will probably also
be seen in future projects.

4.4.7 Dynamism
Factor Outcome
6.1 Cockburn dynamism scale 2/3 Varying
Requirements were quite unclear at the start of the project and during the project the requirements changed
frequently thus resulting in stability level „varying‟. After the project ended, another 1154 hours were spent on extra
features which indicates a relatively small amount of the requirements changed but enough to consider the
dynamism varying. This factor was not used in the choice for the software project management method. The
customer would use a more agile method when the dynamism was ranked as wildly fluctuating and would use a
more plan-driven method when rate of change was stable. The developer would mainly avoid any software project
management method similar to a waterfall method in case of a wildly fluctuating dynamism.

4.4.8 Personnel
Factor Outcome
7.1 Extended Cockburn method skill rating scale Level 2 on average
7.2 Experience – Software development 0 to 30 years
7.2 Experience – Agile methodologies 0 to 3 years
7.3 Education Practical university +

S. de Koning; MSc Thesis Software Project Management Page 28


August 15, 2011
7.4 Project manager type Democratic leadership
7.5 CRACK customer 5/5 Yes
7.6 Project personnel turnover Low
7.7 Familiarity with technology Medium
The project members were ranked according to the extended Cockburn method skill rating scale (Boehm & Turner,
2003a). The skill levels varied from 3 to 1B but on average the skill level was 2 which is relatively high. Although
this did not influence the choice for the software project management method, the project manager would always
demand at least medium skilled personnel in order to be able to run a successful project. Furthermore, a low average
skill level would require a more plan-driven approach because more should be planned and prepared for the project
members than with higher level members.
The experience in the field of software development in the project team varied from 0 to 30 years and the
experience with agile methodologies varied from 0 to 3 years. Especially the experience with agile methodologies
has influenced the choice of the software project management method. Since several team members had several
years of experience with agile methods, this was the preferred method for the project. The project manager would
not have used an agile methodology if none of the team members were experienced with it. Perhaps other team
members would then have been selected. For future projects the developer would also use experience with the
software project management method as a factor in their consideration of methods.
The education level of the team members was at least practical university level for all the members which,
according to the project manager, is normal in this kind of IT-project so this did not and will not play a role in the
choice for a software project management method.
There were three project managers in this case. One from the developer, one from the ICT-department from
the customer and one from the finance and control department who was also product owner. The three project
managers primarily used a democratic leadership style although there were hints of autocratic, laissez-faire and
bureaucratic leadership styles. The democratic leadership style is especially suitable for agile projects so in the
future a leader with this style should prefer an agile software project management method. This also certainly played
a role in this project.
The customer was representative, authorized, committed, knowledgeable and collaborative and thus was a
CRACK customer. While a CRACK customer is very important for Scrum, this can often not be known at the start
of the project. In this case, availability was a problem thus meaning the product owner was a little collaborative but
not fully. This did not have an influence on the choice for a software project management method but in the future it
would perhaps be possible to commit the customer to the project using a contract. So the software project
management method should probably be more plan-driven (adding contracts) if the customer is not fully CRACK
according to the developer.
Project personnel turnover was low in this case. Because of economical reasons two members left and one
joined the team but this did not hinder the project. This factor is not perceived as a factor in the choice for a software
project management method since tacit knowledge that is lost when a team member leaves is often impossible to
capture with adding a plan-driven component.
Two of the developer‟s project members were very familiar with the technology used while the customer‟s
team members had no experience with the technology used. This was however no problem since experience could
be gained during the project. This factor therefore did not influence the choice for the software project management
method. If too little experience with the technology would be a problem in the future, the developer would change
project members and not the software project management method.

4.5 Case D
4.5.1 Case introduction
In 2009 a project was started at a governmental council responsible for the correct execution of laws concerning the
pensions and benefits of war victims. This organization was founded in 1990 and had around 300 employees. The
project‟s aim was to implement a workflow management system with all the necessary basic functionalities to
support the primary business processes of the organization. This project was initiated internally in 2006/2007. Due
to several reasons the project however did not pick up speed. The deadline was set but with the speed during the first
years it would never finish in time. In the beginning of 2009 the customer involved a developer with the project. The

S. de Koning; MSc Thesis Software Project Management Page 29


August 15, 2011
project was then set on the right track using a different software project management method (Prince2 + Scrum)
which enabled it to finish within 9 months, before the deadline in early 2010.

4.5.2 Software project management method


Factor Outcome
Position on planning spectrum Agile---Plan-driven 5/10 Agile + Plan driven
Satisfaction with software project management method 4/5 Satisfied
Added amount of plan-driven components Appropriate
Before the developer was involved in the project, the project was not perceived as a project and was therefore not
consciously managed like a project. The introduction of the developer changed this. After the intervention by the
developer the project was managed using a combination of Prince2 and Scrum as depicted in figure 9. This way the
agile method Scrum could be complemented with the more plan-driven method Prince2. Several roles from the
Prince2 method were used like the project board including a senior user, executive and senior supplier. The
documents and processes from Prince2 were applied and Scrum was used to manage product delivery. Unfortunately
the documentation for this project was no longer completely available but it is expected that considerable
documentation was produced since every iteration had to be reported to management and was documented
internally. The documents were however produced very agile (to-the-point) so perhaps this reduced the size of the
documentation.

Figure 9: Software Project Management method case D Source: Own research


Prince2 was in this case used to give the customer and the developer grip on the project. It provided more control.
To speed up the project, Scrum was used. Scrum therefore provided the speed necessary to complete the project in
time. Prince2 really complemented Scrum on the area of impediments. Where Scrum let‟s you figure out for
yourself, Prince2 has certain roles and a project board which helps solving these problems. Together these two
methods increased the trust the customer had in the success of the project which resulted in more commitment.
Although the software project management method in this case displayed in figure 9 resembles the one in
case C there are significant differences. Prince2 was consciously applied very agile in case D while the agility in
case C came from the application of Scrum for managing product delivery. In case D every component of the
software project management method was done as agile as possible. The software project management method in
case D was consistent and structured while in case C the method itself varied during the project.

4.5.3 Project result


Factor Outcome
Completed on time? 3/5 No, a little later than deadline (<10% late)
Completed within budget? 3/5 No, but less than 10% over budget.
Customer satisfied? 4/5 Satisfied
Developer satisfied? 5/5 Very satisfied
The project eventually was finished a little later than the deadline although this did not prove to be a problem. The
project was also slightly over budget which was also no problem. The customer was satisfied and the developer very
satisfied. The overall view of this project is therefore that it was relatively successful.

S. de Koning; MSc Thesis Software Project Management Page 30


August 15, 2011
4.5.4 Size
Factor Outcome
Project duration 3 to 4 years
3.1 Application size (SLOC) Unknown
3.2 Man-hours 16000 hours
3.3 Project type Create a new product Expansion of an existing
product
3.4 Team Size 16 people
3.5 Size - Complexity 3/5 Complicated
The project eventually took 3 to 4 years in total to complete. Only the last nine months to one year were managed
according to the software project management method previously mentioned. In total 16 iterations were done which
finally delivered about 230 features (user stories).
The number of Source Lines Of Code could not be retrieved. It is agreed that application size in SLOC did
not count in the choice for a software project management method.
It is unknown how many hours have been spent on the project before the involvement of the external
developer. The last year before the deadline however, approximately 16000 hours were spent on the project
according to the hour registration records that have been retrieved. All interviewees however indicate that the
number of man-hours did not influence the choice of the software project management method and will not in the
future.
The project type varied between the creation of a new product and the expansions of an existing product
(some functionality was already present when the external developer was involved). The factor project type did
however not influence the choice of the software project management method and will probably not in the future.
In total, 16 people were involved in the project, not all however were involved fulltime and some of the
people were part of the steering committee which was not involved in the project on a daily basis. 12 People were
project members (developers, customer representatives and a tester). This was also perceived as the maximum
number of people one should form a project group with. When the team size would have increased, the team would
have been split up or the software project management method would have to be applied much more strictly. The
same combination of Prince2 and Scrum would be used however.
The project complexity was rated as complicated where requirements complexity was higher than the
technology complexity. This factor certainly played a role in the choice for Scrum. Since there was a lot of
discussion about the requirements (requirements complexity), the Scrum approach was chosen because of its short
iterations.

4.5.5 Criticality
Factor Outcome
4.1 Loss scale 2/4 Loss of discretionary monies
4.2 Time constraint 5/5 Very high
Failure of this project would have resulted in loss of discretionary monies. The interviewees agree that this factor is
relevant in the choice for a software project management method but they differ in how they would use it. One
would use a more agile method when the potential loss is higher since one of the features in agile software project
management is that the application is continually being tested and adjusted which would lead to higher quality.
Another interviewee would do the opposite by using a more plan-driven method to increase control. A third thinks it
does not matter which approach to take.
The time constraint for this project was high. This has influenced the choice for the software project
management method and introduced the agile approach Scrum. This enabled the project to speed up. In the future,
projects with a high time constraint should also adapt an agile software project management approach.

4.5.6 Culture
Factor Outcome
5.1 Organization type Collins – Customer Bureaucratic organization
5.1 Organization type Collins – Developer Great organization Startup organization
5.1 Organization type Collins – Project team Great organization

S. de Koning; MSc Thesis Software Project Management Page 31


August 15, 2011
5.2 Greiner‟s growth stage 6/8 Control stage
5.3 Trust 3/6 Minimal to 5/6 Good
5.4 Organizational culture Moore – Customer Control culture.
5.4 Organizational culture Moore – Developer Competence culture Collaboration culture
5.4 Organizational culture Moore – Project team Competence culture Collaboration culture
Cultivation culture
The customer‟s organization type was defined as bureaucratic, the project team was defined as a relatively great
organization and the developer was defined as a mix between a great organization and a startup organization. This
factor certainly influenced the choice for the software project management method. The project team and the
developer would have chosen Scrum as their basic approach since they are a great organization (high agility).
Because of the low agility of the customer however (bureaucratic), Prince2 was added. Without adding Prince2,
Scrum would probably not have been accepted by the customer. This factor would have the same influence in future
projects.
The customer in this case is judged to be in the control phase. This has some correlation with the fact that
the customer‟s organization is bureaucratic. Considering the size and age of the organization this seems correct.
Adding Prince2 to the software project management method was a result of the company being in this phase but this
has not consciously been used in the consideration of the software project management method. The interviewees
would also not use this factor in future projects although it probably has influence. Other factors are more suitable.
The trust between the customer and the developer started at minimal. During the project however, it
quickly evolved into good. This enabled the proper use of Scrum and having less need for documentation. Scrum
also helped to gain trust and was therefore also an important factor in its own success.
The organizational culture at the customer was judged to be a control culture while the developer‟s and the
project team‟s cultures are based on competence, collaboration and some cultivation. This directly influenced the
choice for the combination of Prince2 and Scrum. Prince2 was used because of the control culture at the customer
and Scrum was used to provide the agility for the developer and the project team since this fits in their cultures. The
gap between the three cultures was therefore bridged by using a hybrid software project management method. The
same approach would work in a future project.

4.5.7 Dynamism
Factor Outcome
6.1 Cockburn dynamism scale 2/3 Varying
The dynamism was rated at “Varying”. According to the customer 80 percent of the requirements remained stable
while 20 percent changed during the project. Project documentation supports this since the total workload varied
between 460 and 530 Story Points (1SP = approx. 6 productive man-hours) with features that were added and
features that were deleted from the backlog. Because of this Scrum was necessary in the software project
management method to be able to cope with the changes. If the requirements would have been stable, a more plan-
driven method could have been used while a more agile method would be necessary when the requirements would
have been wildly fluctuating.

4.5.8 Personnel
Factor Outcome
7.1 Extended Cockburn method skill rating scale Level 1A / level 2
7.2 Experience – Software development 0 to 30 years
7.2 Experience – Agile methodologies 0 to 6 years
7.3 Education Practical university +
7.4 Project manager type Democratic
7.5 CRACK customer 4/5 Mostly CRACK
7.6 Project personnel turnover Low
7.7 Familiarity with technology Very familiar
The mean skill level of the team was between 1A and 2 which was high enough to use an agile method. If the skill
levels would have been too low to use an agile method like Scrum, the lower skilled project members would have
been replaced by higher skilled ones. If this would not be possible, applying an agile approach would still have been

S. de Koning; MSc Thesis Software Project Management Page 32


August 15, 2011
possible but probably less effective. It is also possible to choose a more plan-driven method in this case or to try to
coach the project members to a higher level.
The project team was quite experienced (between 0 to 30 years of experience) in software development and
was somewhat experienced in agile software development (0 to 6 years experience). Experience does help to
successfully complete the project but it did not influence the choice of the software project management method and
will not in the future. Experience of the project manager with a software project management method does however
have an influence on the choice of the method.
The education level of the project members was at least practical university level. This did however have
no influence on the choice of the software project management method and will not in the future. Education level is
not considered as a good measure of someone‟s abilities.
The leadership style of the project manager was democratic. This certainly influenced the choice of the
Scrum component since without this leadership style, an agile approach would have become difficult. This also
applies to future projects. A project manager with an autocratic leadership style and no possibility to apply another
style will not succeed in using an agile software project management method.
The customer was mostly CRACK in this case which was necessary considering the deadline and the
software project management method. The customer representatives have therefore been chosen based on them
being CRACK. This did not influence the software project management method and will probably not in the future.
Project personnel turnover was low since only one member left and another joined during the project.
Although knowledge is lost when a person leaves the team, this knowledge can often not be kept within the team by
documenting it. Adding plan-driven components is therefore not necessary and will probably add no value on this
area.
The project members were quite familiar with the technology used in the project. This was and will
however not be a factor in the consideration of a software project management method.

S. de Koning; MSc Thesis Software Project Management Page 33


August 15, 2011

5. Results
Chapter 5 will summarize and combine the results from the cases after which the different factors from the
dimensions are judged influential or not. It will start with an introduction in paragraph 5.1, will discuss the
five dimensions in paragraph 5.2 to 5.6 and will conclude the chapter in paragraph 5.7.

5.1 Introduction
This chapter will discuss which factors and dimensions proved to be relevant in the choice of adding (or not adding)
plan-driven components to agile software project management methods. It will start with summarizing the four cases
in a table after which every dimension and their factors are discussed separately with a summarizing table at the start
of every paragraph. Every paragraph contains another table where it is stated if a factor has a positive influence
(higher value means more plan-driven components) or a negative influence (higher value means less plan-driven
components). If the value for a factor in the second table is for example “Yes, +”, this means that it is a significant
factor (Yes) and that it has a positive influence on the amount of plan-driven components (+).
The following table summarizes the results from the cases discussed in chapter 4.
Factor Case A Case B Case C Case D
Completed on time? 5/5 Completed 4/5 Yes, exactly on 4/5 Yes, exactly on 3/5 No, a little later
before deadline. time. time. than deadline
(<10% late)
Completed within budget? 5/5 Yes, we finished 3/5 No, but less than 3/5 No, but less 3/5 No, but less
with some budget 10% over budget than 10% over than 10% over
left. budget. budget.
Customer satisfied? 4/5 Satisfied 4/5 Satisfied 5/5 Very satisfied 4/5 Satisfied
Developer satisfied? 5/5 Very satisfied 5/5 Very satisfied 4/5 Satisfied 5/5 Very satisfied
Overall project result: 5/5 4/5 4/5 3.5/5

Project duration 2 Months Six months 23 Months 3 to 4 years


Software Project Scrum + Sprint 0 Pragmatic Topaz + Prince2 + Scrum Prince2 + Scrum
Management method used? Scrum
Position on planning 1/10 Agile 4/10 More agile than 5/10 Agile + Plan 5/10 Agile + Plan
spectrum? plan-driven driven driven
Satisfied with software pro- 4/5 Satisfied 4/5 Satisfied 4/5 Satisfied 4/5 Satisfied
ject management method?
Satisfied with added amount Appropriate Appropriate Appropriate Appropriate
plan-driven components?
From the table above several things can be deduced. The project in case A was most successful while the project in
case D was relatively less successful compared to the others. The project duration varied from two months to three
to four years. Scrum was used in some form in all cases and was often complemented by Prince2 or a Prince2
variant. The position on the planning spectrum varied from agile in case A to a full hybrid form in case D.
It should be noted that in these four cases it seems that when project duration increases the software project
management method becomes more plan-driven. This relation does however not directly correspond with the
findings from the interviews as will be discussed in the next paragraph. Several other factors will prove to probably
have been the cause for this significant increase in plan-driven components among which culture seems quite
important.
Everybody was quite satisfied with the software project management method that had been used and the amount of
plan-driven components seemed appropriate.

5.2 Size
Factor Case A Case B Case C Case D
3.1 Applications size (SLOC) 23602 LOC Unknown Unknown Unknown
3.2 Man-hours 311,5 hours 4500 hours 9135,5 hours 16,000 hours
3.3 Project type New Create a new New product Create a new
application product Expansion of product

S. de Koning; MSc Thesis Software Project Management Page 34


August 15, 2011
Integrate an existing Expansion of an
existing products product existing product
3.4 Team Size 4 People 6 FTE divided 13 People 16 people
among 3 fulltime
and 12 part-time
3.5 Size - Complexity 4/5 Complex 3/5 Complicated 4/5 Complex 3/5 Complicated
The source lines of code (SLOC) are unknown in all cases but case A due to bad availability and the judgment about
them not being relevant. In no case they could be transformed to function points to provide a good judgment of the
application size. The amount of man-hours was known and varies considerably. One can clearly see that the amount
of man-hours increases from case A to D. This corresponds with the project duration and seems to correspond with
the position on the planning spectrum although this factor is deemed of no influence by the interviewees. While in
case A a new application is created, in cases B, C and D existing products are either integrated or expanded. Case A
seems to have a small project team while cases B, C and D have larger project teams which also seems to relate to
project duration, man-hours and the position on the planning spectrum. Case A and C are considered complex
projects while case B and D are considered complicated as can be seen in figure 10.

Figure 10: Project complexity Source: (Schwaber, 2004)

Legend: =Case A, =Case B, =Case C and =Case D.

Factor Case A Case B Case C Case D Significant


Influence?
3.1 Application size (SLOC) No No No No No
3.2 Man-hours A little A little No No No
3.3 Project type Yes, + A little, + No No Inconclusive
3.4 Team Size Yes, + A little, + A little, + A little, + Yes, +
3.5 Size - Complexity Yes, - Yes, + Yes, + Yes, - Yes, +/-
The factor applications size (SLOC) is of no influence on the position on the planning spectrum since it was
determined to be insignificant in all four cases as can be seen in the table. The factor man-hours also seems to be of
no influence since it was determined to be insignificant or only a little significant. About the factor project type the
result is inconclusive since it seems to be a positive influence in case A and a little bit in case B but in cases C and D
it is of no influence. The scale in these cases starts with new application projects via integrating existing product
projects and expanding existing product projects to repairing existing product projects.
Team size positively influences the position on the planning spectrum since it was proven to be significant
in all four cases and is determined to have a positive influence in all cases. This means that when the team size

S. de Koning; MSc Thesis Software Project Management Page 35


August 15, 2011
increases, the software project management method shifts to the more plan-driven part of the planning spectrum.
Project complexity is also judged to have an influence on the position on the planning spectrum but it is unclear if
this is positive or negative. In cases A and D more complexity means more agility while in cases B and C more
complexity means more plan-driven components. So evidence in all four cases supports the significance of this
factor but differs on the area of positive or negative influence.

5.3 Criticality
Factor Case A Case B Case C Case D
4.1 Loss scale 1.5/4 Loss of 2/4 Loss of 2/4 Loss of 2/4 Loss of
comfort / discretionary discretionary discretionary monies
discretionary monies monies
monies
4.2 Time constraint 4/5 High 4/5 High 4/5 High 5/5 Very high
From the table it can be deducted that all four cases were approximately in the same loss scale (Loss of discretionary
monies) and that the time constraint was high to very high in every case. This means that all four cases were not
distinctively different on the area of criticality.
Factor Case A Case B Case C Case D Significant
Influence?
4.1 Loss scale Yes, + Yes, + Yes, + A little, Yes, +
+/-
4.2 Time constraint No No No Yes No
As can be seen in the table above, the factor “Loss scale” is determined to be a significant factor in all four cases. It
is determined in all cases to have a positive influence on the amount of plan-driven components needed in case of a
higher loss. Time constraint is not considered as a significant factor since evidence in three out of four cases
supports its insignificance.

5.4 Culture
Factor Case A Case B Case C Case D
5.1 Organization Between the four types. Great organization Bureaucratic Bureaucratic
type Collins – organization organization
Customer Hierarchical
organization
5.1 Organization Great organization Great organization Great organization Great organization
type Collins – Startup organization Startup organization
Developer
5.1 Organization Great organization Great organization Great organization Great organization
type Collins – Startup organization
Project Team
5.2 Greiner‟s 5/10 Delegation phase 5/10 Delegation phase 8/10 Red Tape Crisis 6/10 Control stage
growth stage
5.3 Trust 5/6 Good 5/6 Good 3/6 Minimal to 5/6 3/6 Minimal to 5/6
Good Good
5.4 Control culture A little bit of Control culture Control culture.
Organizational Competence culture everything.
culture Moore –
Customer
5.4 Competence culture Competence culture Collaboration culture Competence culture
Organizational Collaboration culture Collaboration culture
culture Moore –
Developer
5.4 Collaboration culture Collaboration Collaboration culture Competence culture
Organizational culture Collaboration culture
culture Moore – Cultivation culture
Project Team

S. de Koning; MSc Thesis Software Project Management Page 36


August 15, 2011
Factor 5.1 is displayed graphically in figure 11 which clearly displays the gaps between the project teams and
developer and the customer.

Figure 11: Collin's good to great matrix Source: Own research + (Boehm & Turner, 2004)

Legend: =Case A, =Case B, =Case C and =Case D. C=Customer, D=Developer and PT=Project Team.

The gaps between the customer and the projectteam/developer can be linked to the position on the planning
spectrum according to paragraph 5.1. While the gap is small in case A and B, the gap in case C and D is
considerably larger and the customers in both cases rank quite low on agility in this quadrant. It seems that this is
one of the causes of the use of a hybrid software project management method to bridge this gap. The gap in case B is
however smaller than expected considering the software project management method. It should therefore be clear
that other factors certainly also have an influence on the position on the planning spectrum.
Figure 12 displays factor 5.2, Greiner‟s growth stages model. It can be seen that the organizations in cases
A, B and D all rank somewhere around the control stage and that the organization in case C is a little bit further and
is now going through the red tape crisis stage. All organizations therefore, according to the interviewees, are in
stages that are less suitable for the application of agile methods.
The trust level in all four cases started with or quickly evolved to good. The customer culture in all four
cases has aspects of a control culture while the developer and the project team in all cases can be ranked as a
collaboration and / or competence culture. There clearly is a gap in all cases between these cultures possibly asking
for a hybrid software project management method.

S. de Koning; MSc Thesis Software Project Management Page 37


August 15, 2011

Figure 12: Greiner's growth stages Source: Own research + (Greiner, 1972)
Legend: =Case A, =Case B, =Case C and =Case D.

Factor Case A Case B Case C Case D Significant


Influence?
5.1 Organization type Collins Yes, - A little, - Yes, - Yes, - Yes, -
5.2 Greiner‟s growth stage A little, + A little, + A little, + No Inconclusive
5.3 Trust Yes, - Yes, - Yes, - Yes, - Yes, -
5.4 Organizational culture Moore No Yes, + Yes, + Yes, + Yes, +
The organization types are in all cases considered as an influential factor. A diagonal axis can be used to determine
the influence where bottom left is the lowest value and top right is the highest value. According to the interviewees,
the factor has a negative influence on the position on the planning spectrum. This means that when an organization
ranks higher on the diagonal axis of Collin‟s good to great matrix it will need less plan-driven components.
The growth stage does not clearly have a negative of positive influence. It is believed it may have a little
positive influence on the amount of plan-driven components but this factor is considered inconclusive because of the
uncertainty.
Trust is considered as a significant factor in all four cases. All cases also support the negative influence of
trust on the amount of plan-driven components. The more trust there is in the relationship between the parties, the
less plan-driven components are needed.
The organizational culture (Moore) is considered to have a positive influence on the position on the
planning spectrum where the scale ranks from low to high by going from collaboration via cultivation and
competence to control culture. When an organization ranks in one of the latter cultures, this positively influences the
position on the planning spectrum according to the evidence in three out of four cases.

5.5 Dynamism
Factor Case A Case B Case C Case D
6.1 Cockburn dynamism scale 2/3 Varying 2/3 Varying 2/3 Varying 2/3 Varying
S. de Koning; MSc Thesis Software Project Management Page 38
August 15, 2011
As can be seen in the table, dynamism was rated at “varying” in all four cases. The four cases are therefore not
distinctively different considering this factor.
Factor Case A Case B Case C Case D Significant
Influence?
6.1 Cockburn dynamism scale Yes, - Yes, - Yes, - Yes, - Yes, -
The dynamism factor is perceived to have a negative significant influence on the amount of plan-driven components
in all four cases. When the dynamism is rated higher, this would result in reducing the amount of plan-driven
components.

5.6 Personnel
Factor Case A Case B Case C Case D
7.1 Extended Cockburn method 4/5 / 5/5 4/5: Level 2 4/5: Level 2 on Betweem 3/5:
skill rating scale Level 2 / Level Developer, average Level 1A and
3 2/5: Level 1B 4/5: Level 2
Customer
7.2 Experience – Software 8 to 20 years 10 to 15 years 0 to 30 years 0 to 30 years
development
7.2 Experience – Agile 4 to 15 years 0 to 3 years 0 to 3 years 0 to 6 years
methodologies
7.3 Education Practical Practical Practical Practical university
university + university. university + +
7.4 Project manager type Democratic Democratic Democratic Democratic
Autocratic leadership
7.5 CRACK customer 5/5 Yes 5/5 Yes 5/5 Yes 4/5 Mostly
CRACK
7.6 Project personnel turnover None High Low Low
7.7 Familiarity with technology Little Medium Medium Very familiar
The skill level in case A is relatively high while the skill levels in the other cases vary between 1B and 2 but always
have a decent skill level. Extensive experience with software development seems to be present in every case but
experience with agile methodologies is more limited. The minimal education level is in every case at least practical
university. The project manager was in each case democratic although in case B there was also a hint of the
autocratic leadership style. In almost all cases the customer was CRACK where case D was the exception since the
customer was not entirely CRACK there. Project personnel turnover was high in case B but low in the other cases.
In case D the project team was very familiar with the technology used while in Case B and C the familiarity was
medium and in case A only a little.
Factor Case A Case B Case C Case D Significant
Influence?
7.1 Extended Cockburn method skill rating scale Yes, - Yes, - A little, - A little, - Yes, -
7.2 Experience No Yes, - A little, - No Inconclusive
7.3 Education No No No No No
7.4 Project manager type Yes, + A little, + Yes, + Yes, + Yes, +
7.5 CRACK customer Yes, - Yes, - A little, - No Inconclusive
7.6 Project personnel turnover Yes No No No No
7.7 Familiarity with technology No A little No No No
As can be seen in the table above, the skill levels of project personnel are considered to have a negative significant
influence on the position on the planning spectrum according to all four cases. This means that a higher skill level
results in less plan-driven components needed. Evidence about the significance of experience differs on the
significance of this factor. The significance of this factor is therefore determined to be inconclusive. Education does
not seem to have any influence on the position on the planning spectrum according to evidence in all four cases.
The project manager type does seem to have a positive significant influence on the position on the planning
spectrum where the scale runs from democratic, via laissez-faire to bureaucratic and autocratic. All four cases
support this. A project with a project manager that uses the autocratic leadership style is therefore possibly
positioned more to the plan-driven side on the planning spectrum. Although having a CRACK customer seems to

S. de Koning; MSc Thesis Software Project Management Page 39


August 15, 2011
have a negative influence on the position on the planning spectrum, the result of this factor is inconclusive since this
is not supported by all cases. Project personnel turnover and familiarity with technology are not considered
significant factors since both factors are determined to be insignificant in three out of four cases.

5.7 Conclusion
The results from the paragraphs in this chapter have been summarized in figure 13. This figure corresponds with
figure 5 from chapter 3 and displays the research framework. The significant difference with figure 5 are the
answers that have been given to the question “Significant influence?”. In this column one can now find if and how a
factor influences the main topic (position on the planning spectrum). There are four possible answers:
 “No influence”, meaning that the factor has been found to be not significant.
 “Inconclusive”, meaning that the data could not support the significance or insignificance of the factor.
 “Yes, positive influence”, meaning that the factor is significant and has a positive influence on the main topic.
 “Yes, negative influence”, meaning that the factor is significant and has a negative influence on the main topic.

Dimensions Factors Significant influence? Main topic


1.1 Time
1. General Project
1.2 Budget
Result General
1.3 Satisfaction
Project
2.1 Software Project
2. Software Project Management Method
Information
Management
2.2 Satisfaction

Dimensions and factors influencing the position on the planning spectrum.


3.1 Application size (SLOC) No influence
3.2 Man-hours No influence

3. Size 3.3 Project type Inconclusive.


3.4 Team size Yes, positive influence
3.5 Complexity Yes, positive or negative

4.1 Loss Scale Yes, positive influence


4. Criticality
4.2 Time constraint No influence

5.1 Organization type Yes, negative influence


5.2 Company growth stage Inconclusive
Position on the
5. Culture planning
5.3 Trust Yes, negative influence
spectrum
5.4 Organizational culture Yes, positive influence

6. Dynamism 6.1 Cockburn dynamism scale Yes, negative influence Agile à Plan-
driven
7.1 Extended Cockburn method
Yes, negative influence
skill rating scale

7.2 Experience Inconclusive


7.3 Education No influence
7. Personnel 7.4 Project manager type Yes, positive influence
7.5 CRACK Customer Inconclusive

7.6 Project personnel turnover No influence


7.7 Familiarity with the
No influence
technology

Figure 13: Factors influencing position on planning spectrum Source: Own research

S. de Koning; MSc Thesis Software Project Management Page 40


August 15, 2011

6. Conclusion
Chapter 6 will provide the conclusion of this thesis. Paragraph 6.1 will provide a discussion of the results and
will discuss the research question and propositions. Paragraph 6.2 will discuss the contributions this thesis
makes to research while the contributions to practice (recommendations to the client) will be discussed in
paragraph 6.3. Paragraph 6.4 will discuss the limitations of this research and will provide the questions that
remain after completing this thesis and which can be studied in future research.
6.1 Discussion
The aim of this research was to answer the research question by testing the five propositions.
The research question for this thesis:
How and when should agile software project management methods be complemented with plan-driven components
to result in a better software project outcome?
This question has been answered by testing the five propositions about size, criticality, culture, dynamism and
personnel. 19 Factors have been studied of which 9 factors have been distinguished as significant influential factors,
the significance of 4 factors could not be determined and 6 factors have been judged as not influential (see figure
13). What is quite remarkable is that a lot of the factors belonging to the dimension „size‟ have been deemed not
influential while increasing size is often linked with the plan-driven home ground in literature .

The five propositions that have been formulated in chapter 1 will now be discussed:
1. When a software project increases in size, the necessity to complement agile software project management
methods with plan-driven components increases.
For the dimension „size‟ only two out of five factors have been judged significant where team size has a positive
influence on the amount of plan-driven components and complexity differs in its positive or negative influence.
These factors were expected to have a positive influence considering existing literature (Beck & Boehm, 2003;
Huang & Han, 2008) but the factors man-hours and application size (SLOC) were also expected to be significant
and influential and were judged not to be. It should be noted however that the application size could not be
measured, possibly clouding the judgment about this factor.
The first proposition is therefore judged as correct considering the information gathered in this research. It
should however be noted that it seems less influential than literature suggest. This could be explained by the fact that
current agile methods are more suitable for larger projects than literature suggests.
2. When the stakes are higher in a software project (criticality), the necessity to complement agile software project
management methods with plan-driven components increases.
Only one out of two factors for the dimension „criticality‟ was judged significant. The time constraint was not
considered a significant factor in the consideration for adding or removing plan-driven components. The seriousness
of possible losses (loss scale) was judged to have a positive influence on the amount of plan-driven components.
This could be explained by the desire to avoid risks in case of a possible high loss (Boehm, 2002; Cockburn, 2006;
Huang & Han, 2008)
3. When the culture is more order and control oriented, the necessity to complement agile software project
management methods with plan-driven components increases.
During the information gathering phase it became clear that the dimension „culture‟ is one of the more important
dimensions influencing the amount of plan-driven components. Three out of four factors were judged to have a
significant influence (organization type, trust and organizational culture) but the significance of the fourth factor
(company growth stage) could not be determined. This seems to correspond with literature (Chan & Thong, 2009;
Strode, Huff, & Tretiakov, 2009). Culture was pointed out as the most important dimension in this framework by
several of the interviewees.
4. When there are high rates of change (high dynamism) in a software project, the necessity to complement agile
software project management methods with plan-driven components decreases.
The dimension „dynamism‟ in this research only consisted of one factor; rate of change according to Cockburn‟s
dynamism scale (Cockburn, 2006) which was found significant. This factor was determined to negatively influence
the amount of plan-driven components although all the studied cases ranked „varying‟ on the dynamism scale so this

S. de Koning; MSc Thesis Software Project Management Page 41


August 15, 2011
could not be seen across the cases. This is however also supported by literature since the agile approach is
considered as the answer to wildly fluctuating requirements (Benefield, 2008; Highsmith, 2002; Sommerville, 2007)
5. When project personnel has low/medium skill levels, the necessity to complement agile software project
management methods with plan-driven components increases.
Only two out of seven factors in the dimension „personnel‟ were judged to significantly influence the amount of
plan-driven components. The skill level (according to the extended Cockburn method skill rating scale) of personnel
influenced their ability to use an agile approach or the necessity to add plan-driven components. When the skill level
was high, this negatively influenced the amount of plan-driven components needed. The project manager type was
also important. A democratic leadership style was very important for the agile approach. A more autocratic style
therefore resulted in adding more plan-driven components. Literature supports this (Boehm & Turner, 2003b;
Cockburn & Highsmith, 2001). The significance of experience and the fact that a customer is CRACK could not be
determined. One would have expected that a high personnel turnover would have a positive influence on the amount
of plan-driven components (documentation) because of the loss of knowledge. The interviewees reason however that
this knowledge can easily be transferred orally and that it is very hard to document tacit knowledge.
Concluding, all dimensions were judged to be significant and influential and primarily in the way the five
propositions describe it. The five propositions can therefore be judged as correct. This research supports Boehm and
Turner‟s statements about the five dimensions (2004). It should be noted however that the dimension „size‟ has less
influence than anticipated and that dimension „culture‟ was the most important dimension.
The research question can therefore now be answered. How and when the software project management
method should be complemented with plan-driven components can be based on the nine significant factors spread
among five dimensions.
6.2 Contributions to research
The current base of scientific research about hybrid software project management approaches and the factors leading
to the choice of a hybrid approach is quite small. The case studies discussed in paragraph 2.4 describe certain hybrid
forms of software project management methods but hardly justify why these combinations were applied and if these
were responsible for the success of the projects studied.
This thesis expands the scientific knowledge about this topic in several ways. It expands an existing model
with five dimensions by Boehm and Turner (2004) with 19 factors of which 9 factors have been determined to
significantly influence the position on the planning spectrum by having a positive or negative influence on the
necessary amount of plan-driven components. The relevance of four factors in the framework could not be
determined although these also seem to have an influence. Six factors were determined to have no influence. This
knowledge can help other researchers interested in this topic in considering factors for their research. Factors which
could not be determined to be significant or not significant should be studied and can be a base for other researchers.
The factors that have been determined to be significant or not significant can and should be tested in other studies
but this thesis provides a small base where other researchers can draw from.
As discussed in this thesis it was hard to gather information about some factors like application size. Other
researchers can draw from this information to try to find other data sources for these factors. Perhaps other
researchers can find other factors that influence the position on the planning spectrum in a similar way.
All four projects in this thesis were completed successfully and the software project management method
was quite important for this success. These four software project management methods expand the existing studies
about practical combinations of software project management methods and therefore expands existing knowledge
about these methods. Paragraph 6.4 discusses more possibilities for future research and limitations of this research
which could be handled by other researchers in future studies.
6.3 Contributions to practice
This thesis expands Boehm and Turner‟s dimensions (2004) with nine significant factors. In practice these should be
considered when choosing a software project management approach. Especially for a starting software project
manager this information could be useful to prevent mistakes.
Software project manager.
A software project manager should always consider the five dimensions when choosing the software project
management method. For the dimension size especially the team size and the complexity should be considered. In
S. de Koning; MSc Thesis Software Project Management Page 42
August 15, 2011
case of a high time-constraint a manager can make the decision to increase the team size. The manager should then
also take into account that additional plan-driven components are possibly needed to properly manage the project
increasing the total workload. The project complexity possibly also asks for more plan-driven components but only
if this decreases uncertainty. In some cases complexity can not be reduced with plan-driven components but an agile
approach could then be useful to tackle the complex problems with small steps.
For the dimension criticality the project manager should determine the possible loss if the project fails and
should increase plan-driven components to provide more security. The manager could then for example produce risk
documentation. As demonstrated in case D this documentation can still be quite agile by only using those
components from for example Prince2 that are necessary.
The project manager should certainly consider the culture within the client, the developer and his/her
personal culture. Sometimes the client will dominate the software project and one can only comply to their culture.
In case of a control culture at the client, one should consider using an agile approach like Scrum or XP internally for
the development and communicate using a more formal plan-driven method like Prince2. This has worked out to be
a very realistic approach providing control and speed like has been described in cases C and D. This is also relevant
in the case of a control culture at the developer. If both the client and the developer have control driven cultures,
there is almost no other option than to adopt a plan-driven software project management method because else both
parties will not accept the approach. Only a high sense of urgency will then enable the use of an agile method. If the
project manager identifies a low level of trust, this will probably result in more plan-driven components like
contracts and reports. The project manager should therefore try to improve the trust between the parties in order to
be able to work more agile. If there is a considerable gap between the cultures at the customer and the developer
considering agility and discipline, the project manager should try to find a software project management method that
will please both parties like has been demonstrated in case D. A hybrid software project management method would
be very suitable in this situation.
If there is high uncertainty (high dynamism) about the requirements the software project manager should
try to make the software project management method as agile as possible since an agile method is better suitable to
handle this.
Considering the personnel dimension, the software project manager should consider several factors. If the
skill level of the project members is low, the project manager should add plan-driven components to ensure quality
and structure. If possible however, the project manager could also replace the lower skilled members with higher
skilled project members in order to be able to work more agile which should be beneficial for the project. The
software project manager should also consider his/her leadership style and match this with the software project
management method. A more autocratic or bureaucratic leader would be wise to use the correct amount of plan-
driven components since this type of leader will probably want to control the project more strict than a democratic or
laissez-faire leader.
Developer organization.
Like the software project manager, the developer organization will have to take the nine significant factors into
account. The developer should be aware of the fact that a larger team needs more plan-driven components and may
therefore not always be better or faster and should consider the complexity of the project when agreeing on a
software project management method. The developer should try to determine with the customer how critical a
project is in order to decide if more control is needed in the form of plan-driven components. The developer should
assess its own organizational culture and type and that of the customer to determine the fitness of the software
project management method and should try to bridge some of the possible gaps between cultures. Developing trust
between both parties should be promoted since this will help reducing the amount of plan-driven components. Like
the software project manager, the developer organization should try to determine the dynamism to consider if a more
agile of plan-driven method is more suitable. The developer organization should always try to invest in skilled
people and use these for their projects. By combining them with junior project members with potential they can
invest in the future and successfully complete their projects. Project members with no potential and lower skill
levels should be avoided for projects using agile or hybrid software project management methods. The developer
should also only appoint a software project manager to a project if the software project management method
matches his/her leadership style. A autocratic leader should not manage a very agile project while a laissez-faire

S. de Koning; MSc Thesis Software Project Management Page 43


August 15, 2011
leader should also certainly not manage a mostly plan-driven method. If there is no choice in software project
managers, the software project management method should be adjusted as much as possible to support the
leadership style of the project manager.
The developer can also consider developing their own hybrid software project management method to use
as an unique selling point when approaching clients. Using the model developed in this thesis will help motivate the
choice for a hybrid software project management method and therefore for the developer like the developer in this
thesis did in case D.
Client organization.
The client organization should be aware of the nine significant factors and should try to choose a developer
organization which fits these factors to increase the chance on a successful project.
If an agile software project management method is preferred one should consider using small teams and
vice versa. The complexity and seriousness of loss should also be considered as mentioned before. It would be very
helpful if the client was aware of its own organization culture and type since matching this with the developer will
probably reduce gaps. If the client however would like to use and learn a different approach to the project, a
developer organization with a culture more fit for agile software project management could be considered. If the
client has low trust in a certain developer, it would be wise to choose another developer which receives more trust.
Less trust results in needing more plan-driven components to compensate for this and will therefore probably
increase overhead. The client should try to allocate high skilled employees to their software projects if a more agile
approach is desired and else should increase plan-driven components to provide the lower skilled employees with
more structure and grip. When selecting a software project manager (internal or external) the client should match
this to the desired software project management method or the other way around.
Apart from these recommendations to the software project manager, developer organization and client
organization, this thesis provides four cases with different software project management methods which could be
used as examples of possible combinations for all parties. In practice one could for example investigate if a
combination of Scrum and Prince2 is an option for the software project management method for their project. This
combination has proven to be successful in the cases and should be considered if a project manager has evaluated
the factors in figure 13 and has decided that a hybrid software project management method should be used.
6.4 Limitations and future research
This research was conducted in the Netherlands and included four relatively diverse cases. It is however uncertain if
the same results would be found in different countries / cultures especially since culture was identified as an
important factor. The cases were selected among the projects that were done by only one developer based in the
Netherlands. It is therefore possible that projects done by other developers would provide different results. The cases
in this thesis only use a limited array of software project management methods (Scrum, Prince2 and Topaz) thus
leaving a considerable amount of methods to be studied by other researchers. All four projects were successfully
completed. Studying less successful / failed projects would expand the knowledge about successful and problematic
software project management methods / combinations further testing the factors and dimensions in this thesis.
It is therefore recommended for future research that this research is expanded to other countries, cultures,
organizations and software project management methods to be able to improve the external validity.
Because of the nature of the cases studied (use of agile approaches) it was hard to obtain objective data
about the projects and a lot of the findings were based on information obtained during interviews. This somewhat
limits the certainty about the objectivity of these findings. This provides an excellent future research opportunity for
other researchers to expand the knowledge base on hybrid software project management approaches with studies
based on objective data and / or more respondents.
As mentioned before, several factors were judged to possibly have an influence on the amount of plan-
driven components but there was not enough conclusive data to fully support this. It could be an option for future
research to study these factors more extensively. Furthermore, this research does not claim to have examined all
possible factors with influence on the added amount of plan-driven components. Future research could expand the
number of factors with this influence.

S. de Koning; MSc Thesis Software Project Management Page 44


August 15, 2011

References

Abdul-Rahman, A., & Hailes, S. (1997). A distributed trust model. Proceedings of the 1997 workshop on New
security paradigms - NSPW ’97, 48-60. New York, New York, USA: ACM Press.
doi:10.1145/283699.283739

Ashworth, C. (1988). Structured systems analysis and design method (SSADM). Information and Software
Technology, 30(3), 153-163. doi:10.1016/0950-5849(88)90062-6

Beck, Kent. (1999a). Embracing Change with Extreme Programming. IEEE Computer, 32(10), 70-77.

Beck, Kent. (1999b). Extreme Programming Explained. Philosophy. Addison Wesley.

Beck, K., & Boehm, B. (2003). Agility through discipline: a debate. Computer, 36(6), 44-46.
doi:10.1109/MC.2003.1204374

Beck, Kent, Beedle, M., Bennekum, A. van, Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., et al. (2001).
Manifesto for agile software development. Retrieved from http://agilemanifesto.org

Benefield, G. (2008). Rolling Out Agile in a Large Enterprise. Proceedings of the 41st Annual Hawaii International
Conference on System Sciences (HICSS 2008), 461-461. Ieee. doi:10.1109/HICSS.2008.382

Boehm, B. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5), 61–72. IEEE.

Boehm, B. (2002). Get ready for agile methods, with care. IEEE Computer, 35(1), 64-69. doi:10.1109/2.976920

Boehm, B. (2006). A view of 20th and 21st century software engineering. Proceeding of the 28th international
conference on Software engineering - ICSE ’06, 12. New York, New York, USA: ACM Press.
doi:10.1145/1134285.1134288

Boehm, B., & Turner, R. (2003a). Observations on balancing discipline and agility. Proceedings of the Agile
Development Conference, 2003. ADC 2003, 32-39. Ieee. doi:10.1109/ADC.2003.1231450

Boehm, B., & Turner, R. (2003b). People Factors in Software Management : Lessons From Comparing Agile and
Plan-Driven Methods. The Journal of Defense Software Engineering, 4-8.

Boehm, B., & Turner, R. (2004a). Balancing Agility and Discipline: A Guide for the Perplexed. Addison Wesley.

Boehm, B., & Turner, R. (2004b). Balancing agility and discipline: evaluating and integrating agile and plan-driven
methods. Proceedings. 26th International Conference on Software Engineering, 718-719. IEEE Comput. Soc.
doi:10.1109/ICSE.2004.1317503

Chan, F. K. Y., & Thong, J. Y. L. (2009). Acceptance of agile methodologies: A critical review and conceptual
framework. Decision Support Systems, 46(4), 803-814. Elsevier B.V. doi:10.1016/j.dss.2008.11.009

Cockburn, A. (2006). Agile software development: The Cooperative Game (2nd ed.). Addison wesley.

Cockburn, A., & Highsmith, J. (2001). Agile software development: The people factor. Computer, 34(11), 131-133.

Cockburn, A., Bingham, K., Paulk, M. C., Mcmahon, P. E., Col, L., Palmer, G. A., Bowers, P., et al. (2002). Agile
Software Development. The Journal of Defense Software Engineering, 15(10). Addison wesley.

S. de Koning; MSc Thesis Software Project Management Page 45


August 15, 2011
DeMarco, T., & Boehm, B. (2002). The agile methods fray. IEEE Computer, 35(6), 90-92.
doi:10.1109/MC.2002.1009175

Deemer, P., Benefield, G., Larman, C., & Vodde, B. (2010). The Scrum Primer. Development (pp. 1-22).

Fowler, F. J. (1995). Improving survey questions: Design and evaluation (Vol. 38). Thousand Oaks: Sage
Publications, Inc.

Greiner, L. E. (1972). Evolution and revolution as organizations grow. 1972. Harvard business review, 76(3), 55-60,
62-6, 68.

Highsmith, J. (2002). Agile Software Development Ecosystems. Boston: Addison Wesley.

Huang, S., & Han, W. (2008). Exploring the relationship between software project duration and risk exposure: A
cluster analysis. Information & Management, 45(3), 175-182. doi:10.1016/j.im.2008.02.001

IBM. (2011). IMB - Rational Unified Process (RUP). Retrieved July 20, 2011, from http://www-
01.ibm.com/software/awdtools/rup/

IEEE. (2011). IEEE SA - 12207.0-1996 - IEEE Standard for Information Technology - Software Life Cycle
Processes. Retrieved July 11, 2011, from http://standards.ieee.org/findstds/standard/12207.0-1996.html

Karlström, D., & Runeson, P. (2006). Integrating agile software development into stage-gate managed product
development. Empirical Software Engineering, 11(2), 203-225. doi:10.1007/s10664-006-6402-8

Kniberg, H. (2007). Scrum and XP from the trenches. Online. Toronto: C4Media.

Lewin, K, Lippitt, R., & White, R. (1939). Patterns of aggressive behavior in experimentally created social climates.
Journal of Social Psychology, 10, 271-301.

Lewin, Kurt. (1944). A research approach to leadership problems. Journal of educational sociology, 17(7), 392-398.

Manzo, J. (2002). Odyssey and Other Code Science Success Stories. Crosstalk, 19-22.

Middleton, P., & Joyce, D. (2011). Lean Software Management: BBC Worldwide Case Study. IEEE transactions on
Engineering Management, PP(99), 1-13.

Moore, J. W., & Rada, R. (1996). Organizational Badge Collecting. Communications of the ACM, 39(8), 17-21.

Nawrocki, J., Olek, L., Jasinski, M., Paliświat, B., Walter, B., Pietrzak, B., & Godek, P. (2006). Balancing agility
and discipline with xprince. Rapid Integration of Software Engineering Techniques, 266–277. Springer.

Nonaka, I. (1994). A Dynamic Theory of Organizational Knowledge Creation. Organization Science, 5(1), 14-37.
doi:10.1287/orsc.5.1.14

Office of Government Commerce. (2009). Managing Successful Projects With Prince2. TSO.

Oliveira Basto da Silva, J. G. a, & Rupino da Cunha, P. (2006). Reconciling the Irreconcilable? A Software
Development Approach that Combines Agile with Formal. Proceedings of the 39th Annual Hawaii
International Conference on System Sciences (HICSS’06), 00(C), 216b-216b. Ieee.
doi:10.1109/HICSS.2006.408

Onna, M. van, & Koning, A. (2010). De kleine prince 2. Academic Service.

S. de Koning; MSc Thesis Software Project Management Page 46


August 15, 2011
Oppenheim, A. N. (1992). Questionnaire Design, Interviewing and Attitude Measurement (p. 310). Pinter Pub Ltd.

Palmer, S. R., & Felsing, J. M. (2002). A Practical Guide to Feature-Driven Development (1st ed.). Prentice Hall.

Petersen, K., & Wohlin, C. (2009). A comparison of issues and advantages in agile and incremental development
between state of the art and an industrial case. Journal of Systems and Software, 82(9), 1479-1490. Elsevier
Inc. doi:10.1016/j.jss.2009.03.036

Poppendieck, M., & Poppendieck, T. (2003). Lean Software development: An Agile Toolkit. Addison Wesley.

Qumer, A., & Henderson-sellers, B. (2008). A framework to support the evaluation, adoption and improvement of
agile methods in practice. Journal of Systems and Software, 81(11), 1899-1919. doi:10.1016/j.jss.2007.12.806

Royce, W. W. (1970). Managing the development of large software systems. IEE Wescon, (August), 1-9.

Schwaber, K. (1997). Scrum development process. OOPSLA Business Object Design and Implementation, 10-19.

Schwaber, K. (2004). Agile Project Management with Scrum. Redmond: Microsoft Press.

Schwaber, K., & Beedle, M. (2002). Agile Software Development with Scrum. Prentice Hall.

Shingo, S. (1989). A Study of the Toyota Production System from an Industrial Engineering Viewpoint.
Manufacturing Engineer. Productivity Press.

Software Engineering Institute. (2011a). CMMI | Case Studies | Process Maturity Profiles | SW-CMM. Retrieved
July 11, 2011, from http://www.sei.cmu.edu/cmmi/casestudies/profiles/swcmm.cfm

Software Engineering Institute. (2011b). CMMI | Overview. Retrieved July 11, 2011, from
http://www.sei.cmu.edu/cmmi/

Sommerville, I. (2007). Software engineering (8th ed., pp. 396-398). Essex: Pearson Education Limited.

Stapleton, J. (1997). DSDM, Dynamic Systems Development Method: the method in practice. Technology of Object-
Oriented Languages and Systems. Addison Wesley.

Stephens, M., Rosenberg, D., Board, E., Appleman, D., Berry, C., Cornell, G., Davis, T., et al. (2003). Refactored :
The Case Against XP Extreme Programming Refactored : The Case Against XP. Berkeley: Apress.

Strauss, A. C., & Corbin, J. M. (1998). Basics of Qualitative Research: Grounded Theory Procedures and
Techniques (2nd ed.). Sage Publications.

Strode, D. E., Huff, S. L., & Tretiakov, A. (2009). The impact of organizational culture on agile method use. hicss
(pp. 1–9). IEEE Computer Society.

Sutherland, J., Jakobsen, C. R., & Johnson, K. (2008). Scrum and CMMI Level 5: The Magic Potion for Code
Warriors. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008),
466-466. Ieee. doi:10.1109/HICSS.2008.384

Turner, W. S. (1987). SDM, Systems Development Methodology. New York, New York, USA: Elsevier Science Inc.

Yin, R. K. (2009). Case study research: Design and Methods (4th ed.). Sage Publications.

S. de Koning; MSc Thesis Software Project Management Page 47


August 15, 2011

Appendix A: Case study interview / data gathering questions.


Factor s and corresponding questions
1.1 Project success/failure based on agreements on start of project.

a. Could you give a short introduction of the project?

b. Has the project been completed on time?

c. Was the project completed within budget?

d. How satisfied was the customer with the end product?

e. How satisfied was the developer with the end product?

f. What (combination of) software project management method(s) was used?


g. Was the software project management method important in achieving this result? How?
h. Did adding plan-driven components (if so) have an influence on the success of the project?
i. What would you have done different in retrospective?
2.1 Software project management method.
a. How many and which plan-driven components were added to the basic agile development method? Why?
b. Were you satisfied with this approach?

c. What did you think about the added amount of plan-driven components?

d. Who initiated/suggested adding plan-driven components? Why?

3.1 Size – Source Lines of Code / function points

S. de Koning; MSc Thesis Software Project Management Page 48


August 15, 2011
By determining the SLOC and the language we can produce, using a gearing factor, the number of function points to
compare the size of the projects.
a. How many Source Lines Of Code does the developed product contain?
b. Which language(s) was/were used and in what ratio?
c. Do you think the application size in SLOC influenced the choice of the software project management
method? How?
d. How would you use the estimated SLOC in your decision for a software project management method?
3.2 Size – Man-hours
a. How many man-hours were spent by the entire project team on the project?
b. How many hours were spent on project management?
c. How many hours were spent by the customer representative (Product Owner)?
d. Do you think the project size in hours influenced the choice of the software project management method?
How?
e. How would you use the estimated project hours in your decision for a software project management
method?
3.3 Size – Project type
Projects can be very different. It can create a new product, be an expansion of an existing product, integrate existing
products or repair an existing product.
a. What kind of product was created during the project? A new product, expansion of an existing product,
integration of existing products or a repair of an existing product?
b. Do you think that the type of project has influenced the choice for the software project management
method? How?
c. How would you use the project type in your decision for a software project management method?
3.4 Size – Staff/team size(Highsmith, 2002)
a. What was the average team size including project manager and product owner?
b. Do you think the team size has influenced the choice for the software project management method? How?
c. How would you use the team size in your decision for a software project management method?
3.5 Size – Complexity (Schwaber, 2004)

Vertical: Requirements complexity.


Horizontal: Technology Complexity.
Please rate your project on a scale from 0 to 10 on:
a. Requirements complexity (0 is Very close to agreement and 10 is very far from agreement).

b. Technology complexity (0 is very close to certainty and 10 is very far from certainty).

c. Do you think the complexity of the project has influenced the choice for the software project management
method? How?
d. How would you use the complexity in your decision for a software project management method?

S. de Koning; MSc Thesis Software Project Management Page 49


August 15, 2011
4.1 Criticality – Loss scale
(Cockburn, 2006; Highsmith, 2002)
a. Please indicate in which category you would rank the project:

a. Do you think the criticality of the project ranked in type of loss has influenced the choice for the software
project management method? How?
b. How would you use the criticality of the project ranked in type of loss in your decision for a software
project management method?
4.2 Criticality – Time constraint
a. What was the time constraint during the project?

b. Do you think the time constraint has influenced the choice for the software project management method?
How?
c. How would you use the time constraint in your decision for a software project management method?
5.1 Culture – Organization type Collins’ “good-to-great matrix” (Boehm & Turner, 2004)

a. How would you rank the customer‟s organization according to the above matrix? Why?
b. How would you rank your own organization according to the above matrix? Why?
c. How would you rank the project team according to the above matrix? Why?
d. Do you think the organization type has influenced the choice for the software project management method?
How?
e. How would you use the organization type in your decision for a software project management method?
5.2 Culture – Greiner’s growth stage (Greiner, 1972)

S. de Koning; MSc Thesis Software Project Management Page 50


August 15, 2011

a. In which stage would you rank the customer‟s company? Why?


b. Do you think the company age (stage of growth or crisis) has influenced the choice for the software project
management method? How?
c. How would you use the company age (stage of growth or crisis) in your decision for a software project
management method?
5.3 Trust between customer and developer (Abdul-Rahman & Hailes, 1997)

a. How would you rank the level of trust between the customer and the developer in this project? Why?
b. Do you think trust has influenced the choice for the software project management method? How?
c. How would you use the trust level in your decision for a software project management method?
5.4 Culture – Four basic organizational cultures: cultivation, competence,
collaboration, and control (Moore 2000). From (Highsmith, 2002)
Competence Culture: This culture is focused on people‟s competence and not on rank or external pressure.

S. de Koning; MSc Thesis Software Project Management Page 51


August 15, 2011
Management should first be technically competent and secondly management competent.
Control culture: Power based and security oriented. Stick with the plan.
Collaboration culture: Strong leadership, teamwork, consensus. Teams are in a prominent position.
Cultivation Culture: Individuals are put first. They can work on what they find interesting. Structure is hard to find.
a. How would you categorize the organizational culture of the client? Why?
b. How would you categorize the organizational culture at the developer? Why?
c. How would you categorize the organizational culture within the project team? Why?
d. Do you think the organizational culture within the client, the developer and/or the team has influenced the choice
for the software project management method? How?
e. How would you use the organizational culture within the client, the developer and/or the team in your decision for
a software project management method?
6.1 Dynamism – Cockburn dynamism scale (Cockburn, 2006)
Cockburn distinguishes three stability levels for dynamism: wildly fluctuating, varying and relatively stable.
a. How would you have ranked the stability level of the requirements and demands during the project? Why?
b. Do you think the stability level of the client, the developer and/or the team has influenced the choice for the
software project management method? How?
c. How would you use the stability level of the client, the developer and/or the team in your decision for a software
project management method?
7.1 Personnel – Extended Cockburn method skill rating scale (Boehm & R. Turner, 2003a, 2003b)
Levels of Software Method Understanding and Use (after Cockburn)
Level Characteristics

3 Able to revise a method (break its rules) to fit an unprecedented new situation

2 Able to tailor a method to fit a precedented new situation

1A With training, able to perform discretionary method steps (e.g., sizing stories to fit increments,
composing patterns, compound refactoring and complex COTS integration). With experience, can
become Level 2.

1B With training, able to perform procedural method steps (e.g., coding a simple method, simple
refactoring, following coding standards and CM procedures, running tests). With experience, can
master some Level 1A skills.

–1 May have technical skills, but unable or unwilling to collaborate or follow shared methods.
a. How would you rank the individual project members? Why?
b. How would you rank yourself? Why?
c. Do you think the Cockburn skill level of the project members has influenced the choice for the software project
management method? How?
d. How would you use the Cockburn skill level of the project members in your decision for a software project
management method?
7.2 Personnel – Experience
a. How many years of experience do you have in the field of software development?
b. How many years of experience do your project colleagues have in the field of software development?
c. How many years of experience do you have using agile methodologies?
d. How many years of experience do your project colleagues have using agile methodologies?
e. Do you think the experience of the project members has influenced the choice for the software project
management method? How?
f. How would you use the experience of the project members in your decision for a software project management
method?
7.3 Personnel – Education
a. What is your highest completed education? In which field?
b. What is the highest completed education followed by your project colleagues? In which field?
c. Do you think the education level of the project members has influenced the choice for the software project
management method? How?
d. How would you use the education level of the project members in your decision for a software project
management method?

S. de Koning; MSc Thesis Software Project Management Page 52


August 15, 2011
7.4 Personnel – Project manager type
We distinguish four basic leadership types: Autocratic, Bureaucratic, Laissez-faire and Democratic.
a. How would you describe the leadership style of the project manager in this project? Why?
b. Do you think the project manager‟s leadership style has influenced the choice for the software project
management method? How?
c. How would you use the project manager‟s leadership style in your decision for a software project management
method?
7.5 CRACK customers
Collaborative, Representative, Authorized, Committed, Knowledgeable (Boehm & Turner, 2003)
a. Has the customer been collaborative?
b. Has the customer been representative for the company?
c. Did the customer have enough authorization to make decisions?
d. Was the customer committed to the project?
e. Was the customer knowledgeable?
f. Do you think these factors have influenced the choice for the software project management method? How?
g. How would you use these factors in your decision for a software project management method?
7.6 Project personnel turnover
a. Were there any changes in the project team during the project?
b. Which persons/roles changed? Why?
c. Do you think this factor has influenced the success of the software project management method? How?
d. How would you use this in your decision for a software project management method?
7.7 Familiarity with the technology
a. How well did the developers know the technology that was going to be used in the project?
b. How well did the customer know the technology that was going to be used in the project?
c. Do you think these factors have influenced the success of the software project management method?
d. How would you use this in your decision for a software project management method?
Is there anything you would like to add?

S. de Koning; MSc Thesis Software Project Management Page 53