Software Project Success Despite Resource
Starvation?
An Exploratory Study on Coping with Resource Scarcity in The Netherlands
Ravish Gopal
Amsterdam, 201560 pages
A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering
Supervisor: drs. Hans L. Dekkers Host organisation: Universiteit van Amsterdam
Un i v e r s i t e i t va n A m s t e r da m
Fac u lt e i t d e r Nat u u rw e t e n s c ha p p e n , Wi s k u n d e e n I n f o r m at i c a M a s t e r S o f t wa r e E n g i n e e r i n g
Contents
Abstract 3 1 Introduction 4 1.1 Relevance 4 1.2 Research Question 5 1.3 Outline 5 2 Theoretical Background 62.1 Root of all Evil: Resource starvation 6
2.2 Definitions 7
2.3 Project vs Organisational Perspective 8
2.4 Uncertainty 9
2.5 Learning 10
2.6 Practical software example 10
2.7 Conceptual Model 11
3 Preventing vs Utilising Resource Scarcity 13
3.1 Advantages of Prevention 13
3.1.1 Balancing Work to Capacity 15 3.2 Will Prevention really Prevent Waste, Waiting and Chaos 16 3.3 A Different Approach: Utilising Resource Scarcity 17
3.4 Summary 18
4 Grounding the Theory in Literature 20
4.1 Stress and Performance 20
4.2 Adaptive Performance 21
4.3 Leadership 22
4.4 Decision Making 23
4.5 Project Termination Effects 24
5 Method 27 5.1 Theory Building 27 5.2 Questionnaire Development 28 5.3 Data Collection 28 5.3.1 Part I 28 5.3.2 Part II 29 5.4 Participants 29 5.5 Analysis 30 5.6 Validity 30
6 Findings on Theory and Questionnaire 31 6.1 Findings on Theory 31 6.1.1 Additions 31 6.1.2 Confirmations 32 6.1.3 Corrections 35 6.2 Findings on Questionnaire 35 6.3 Reflection 36 7 Questionnaire Evaluation 37 7.1 General 37 7.2 Validity 37 7.3 Theory in Practice 39
8 Discussion and Conclusion 41
9 Appendix 44
9.1 Survey 44
9.2 Rationale for Interview Conclusions 53
9.2.1 Interview 5 53
9.2.2 Interview 6 54
9.2.3 Interview 7 55
Abstract
Scarcity of human resources is a problem for many software projects. Scientific literature on this topic is insuffi-cient. Moreover, organisations are lacking insight in dealing with this problem.
This thesis studies the role of resource scarcity with respect to organisational strategy for software projects. Two strategies are analysed and discussed. A theory is developed to explain what effects resource scarcity has on project success and how resource scarcity could aid in value creation. Furthermore, a survey is developed for data collection on how Dutch organisations approach and deal with resource scarcity.
Data is collected through semi-structured interviews with experienced IT project and program managers. Findings show that the effects of resource scarcity and its related problems are recognised and that the project and program managers are already applying the strategy developed in this thesis to various extents.
I
|
Introduction
“When resources are scarce, it is the resourceful who prevail.” - Faisal Khosa
T
h e r e i s a lot of scientific literature available on the means and usage of resources in production processes.Its purpose is to optimise resource allocation and usage for higher productivity, production quality and lower cost [GCW92,Rot09,TN86].Over the last two decades, there has been an effort to apply resource optimisation theories from manufactur-ing to software development with the goal of improvmanufactur-ing the development process and consequently increasmanufactur-ing successful project delivery (thus reducing project failure) [Ket09,RKH09,Ran00].
Although the adoption of these translated techniques has been widespread in industry, there are still a consid-erable number of projects that are problematic or even fail [LMV+
14]. An often used explanation by software project managers is that these problems follow from a shortage of human resources that are needed for successful project delivery [VE14,LG08]. Several studies found availability of (specific) resources to be a risk factor or even a reason for cancellation of software projects [Lin99,EEK08,WD13,LMV+
14]. Moreover, although the availability of resources - human resources in particular - plays an important role in project outcome, it is not clear what the relationship between human resource availability and project outcome exactly entails. More importantly, there is insufficient literature available that explains this dynamic in the context of software engineering. There is also little data available on how organisations actually deal with resource scarcity in relation to project outcome.
It is therefore not clear whether the software engineering process can be significantly improved by focusing on preventing resource scarcity through application of resource scheduling optimisation in projects. Exploring this relationship and shedding light on the elements that add to the complexity of the relationship between resource scarcity and project outcome would give insight into what the focus of further research should be.
This study will take organisational strategy and software complexity into account for the exploration of the relationship in the context of a multi-project environment. In addition, a theory will be developed on how to deal with resource scarcity with respect to value. Furthermore, semi-structured interviews will be conducted to test the theorizing in this study. The interviews are also used to create a questionnaire for collecting data about practices of Dutch IT organisations with respect to resource usage in software projects.
1.1
Relevance
The outcome of this study can make a worthwhile contribution.
Few studies are available about effective resource allocation in software projects. Early research on resource op-timisation focused on manufacturing processes from the perspective of construction engineering [Heg99]. More recently, the field of software project scheduling studies resource allocation in the software engineering domain, attempting to solve project scheduling problems. These studies describe the computation of optimal resource distribution using algorithms, such as genetic algorithms, ant colonisation and fuzzy algorithms [XAT13].
However, these studies do not account for changes in the project, such as changes in the project goal or unexpected complexity in the solution domain, which affect the required type or amount of resources for the project. This study will make a contribution to software engineering literature by exploring the relationship between resource scarcity and project outcome, while accounting for fluctuations in the project.
What is more, there is very little empirical data available about (actual) resource allocation and usage in the Netherlands. This study will start with the development of a questionnaire to broaden the understanding in this area and produce the data that indicates the state of this field.
1.2
Research Question
Goal
The goal of this thesis is to provide a theoretic understanding of factors that complicate efficient software project management with respect to availability of human resources.
Furthermore, another goal is to develop a questionnaire, which can be used to give insight in the relationship between resource availability, effort and value, and the variables that affect these relationships.
Research question
The following research question is defined to reach the thesis goal: What is the effect of scare allocation of resources on project success? Sub-questions:
1. What problems can occur as a result of resource scarcity? 2. Do these problems impede project progress?
3. How does resource scarcity impact value creation?
4. Would organisations benefit from the prevention of resource scarcity? 5. Why can there be achieved more with less resources?
1.3
Outline
The thesis starts with a background on project work and value creation, and the issues of multi-project-environments. Next, chapter 3 introduces a vocabulary and a project model to facilitate analysis. This is followed by an analysis of a theory for preventing resource scarcity and introduction of a newly developed theory in chapter 4. The next chapter provides a theoretical framework for this theory. Chapter 6 describes the methodology, which is followed by two chapters on findings and analysis. Finally, the last chapter presents the discussion and conclusion.
II
|
Theoretical Background
W
hat i s t h e g oa l of a software development project? In general, it means producing a software productthat satisfies the needs of the client. By satisfying this need, the produced software provides value. This implies software development organisations are in the business of providing value to their customers by producing software. Projects are temporary vehicles for delivering value and use time, money and people and other resources to accomplish this [BH06].Figure 2.1 Marginal benefit of value as the number of projects increases.
The easiest way for an organisation to increase the output is to increase the number of projects. However, organi-sations do not have unlimited resources, which means that each newly added project to the group of currently active projects has less output potential, partially because there are less resources per project and each new project puts more strain on the whole organisation.
Another influence is the law of diminishing returns with respect to value: projects can deliver a lot of value, but also very little value. Doing more projects therefore also means spending organisational resources on projects of little value. This is illustrated in figure 2.1, which shows the marginal output benefit of increasing the number of active projects in an organisation.
2.1
Root of all Evil: Resource starvation
Unfortunately, organisations still run into problems in this production process, which affects the value they can deliver to their clients. Moreover, many of these problems are interrelated and not only affect the projects themselves, but also the organisation as a whole [LMV+
14]. Van Egmond has studied problematic projects and observed interrelated problems as well. He assessed that there is a root cause for these problems, which is the situation where an organisation has started more projects than it can handle [VE14]. He also hypothesises that projects will run better if organisations start up less projects, at least not more than they can handle.
This observation can be translated in to the relationship between the workload and the capacity of the human resources in an organisation. Van Egmond’s observes that workload (vastly) exceeds capacity, which puts too
much strain on the individual resources and the entire organisation, causing all kinds of problems. His hypothesis argues for an equilibrium between the two, which would prevent the majority of problems.
Is it likely that software projects fail because organisations are starting up too many projects? Would prevention of this also result in better projects?
2.2
Definitions
Here a vocabulary of element definitions is introduced which are related to the project process, such as work and capacity. The vocabulary is referenced throughout the thesis for further reasoning.
Moreover, this vocabulary is used to limit the scope of project elements that are relevant to the research question. Having this vocabulary facilitates systematic analysis of literature and empirical data.
Work
Karl Marx describes labour as the process of using human effort to transform natural ingredients to the subject of that effort, using instruments, measured in the time it takes to complete that transformation [Mar75, Chapter 7]. This description explains the process of manual labor at the time of publication (1867).
A more general understanding can be found in Merriam Webster’s definition, where work is described as the ongoing physical or mental effort to achieve a desired outcome [Wor14]. This implies that a goal is set upfront, which is the target of the work to be performed.
In the context of this thesis, the following definition is introduced:
(1) “Work is the effort required to achieve a goal.”
This definition is quite broad. Therefore, the work constructs task and activities are introduced, to facilitate more detailed reasoning about work:
Figure 2.2 The constructs goal, tasks and activities.
In order to actually put effort into work, it is necessary to describe the work in more detail. This means that work needs to be described in a set of tasks and activities, before they can be executed. For example, when the goal is to build a house, several tasks are identified, such as laying the foundation, putting up the frame, etc. Thus, tasks are means to achieve the goal, with each task consisting of the execution of several activities.
Productivity
Marx further stated that the natural measurement of labour is time [Mar75, Chapter 7]. Using time to measure work effort, the speed at which the goal is reached represents the productivity of the worker. Productivity is variable, meaning that work can be done faster or slower. It can also vary in between tasks belonging to the same goal.
However, in knowledge work, such as software engineering, it is important to get the work done first. Only after the goal is achieved and the necessary tasks and activities are identified, can one start with optimisation in an attempt to increase productivity. The optimisation involves reducing the number of hours required to achieve the goal. It is important that goal achievement time is used and not task completion time. Ackoff [Ack93] explains that sub optimisation has a negative effect on the whole, and instead the focus should be on optimising the whole.
On the other hand, productivity can also be expressed as the ratio between value and cost in the economic sense. Increasing productivity would mean lowering the cost of the current value or increasing produced value while keeping cost fixed.
In this thesis however, the following definition is used:
(2) “Productivity is the number of man-hours it takes to achieve a work goal.”
Value
Marx [Mar75, Chapter 7], also described that the result of work has a use-value and an exchange-value. Complet-ing a unit of work gives immediate use-value, however its exchange-value is yet unknown and is decided by the receiver of the work. A carpenter building a big wooden door means the door itself has use-value: it can function as a door right after production. It obtains exchange-value once someone has a need or purpose to use that door (for example to close a room in their house), and therefore requests it from the carpenter.
However, when it to a business setting, value is any development that improves the bottom line of an organisa-tion, be it more revenue, lower cost, lower risk, increasing market capitalisaorganisa-tion, etc.
Also used in this document is the following definition of value:
(3) “Value is the degree by which work improves the bottom line of an organisation.”
This means that value is not binary, either being there or not; slight improvement is also possible, meaning that the work could not fully satisfy, but still could be acceptable.
Skill
Work is not homogeneous, meaning that no work is the same, even if the same work is done twice. One reason for this is a difference in skill between the people doing the work. A higher skill allows for better decision making, which enables faster task completion and/or goal achievement. A professional can develop his or her skill while doing work that is challenging to their current skill. Skill is therefore gained through training and experience.
(4) “Skill is the competence to make the right decisions combined with high productivity for known work.”
Capacity
In knowledge work such as software engineering work is done by people. Within projects and also this thesis -people are referred to as (human) resources. For reasoning purposes, the following definition is used to refer to (multiple) resources:
(5) “Capacity is the amount of available resources.”
2.3
Project vs Organisational Perspective
Projects are traditionally viewed as independent of other projects [LG08]. Adding another project to the project pool cannot happen independently as there is only one resource pool. If a resource that is needed for the new project is still working on an older project, the new project has to wait for that project to finish. Projects in a
multi-project environment are therefore not independent, but instead are competing for the same resources, meaning that any new project added to the project pool exacerbates resource availability issues and thereby hinders progress of other projects.
In such multi-project environments, project managers compete with each other over scarce resources from the need for special knowledge [LG08]. Once a project is running, the necessity of its allocated resources for project success prevents other projects to allocate these resources. This leads to resource lobbying and increased competition for resources. Van Egmond argues this is a harmful situation which creates problems and hinders project progress [VE14].
There is a difference in the project perspective and the organisational perspective. What is bad for the project might be good for the organisation and vice versa. For example, an organisation could decide to stop a project half way to completion because it needs the resources for a project that is much more valuable. More projects means more value creation and more earning potential, which is good for the organisation, but also means scarcely staffed projects, which in turn might prevent social loafing [KW97] but puts more strain on the projects and their resources and hinders the project schedule.
Organisations therefore are dealing with the problem that more projects means more earning potential, but at the same time increases resource scarcity and limits projects’ progress [LG08]. This means that organisations need to use a strategy which finds a compromise between organisational goals, project portfolio and resource scarcity issues.
2.4
Uncertainty
In traditional production systems the work (each production/assembly activity) is clear, because it has stan-dardized processes which only build one solution and the production system has highly predictable behaviour. Producing a pen involves sourcing the ingredients (plastic, metal, ink) and specifying the molding and assembly, whereby each activity has a predictable outcome. An example of an activity would be inserting a spring in a pen tube. There are no surprises here and only one way of inserting the spring. The goal, tasks and activities are all clear.
In software engineering (and knowledge work) a project starts with a goal definition, but it is not immediately clear how this goal can be reached and who is needed for this. To bring the goal closer, tasks need to be identified, followed by identification of activities for a task. However, these tasks and activities can only be described or in other words defined and not specified. The definitions are part of a plan that give direction towards achieving the goal. However, there is no guarantee that execution of the plan gives the desired outcome. The reason for this is uncertainty, which is inherent and inevitable in software engineering, as explained by Ziv et al. [ZRK97]:
1. Goal - this is known upfront, but may not be clear. Ziv et al. explain that is very difficult to assess whether there is appropriate domain knowledge when setting a goal [ZRK97].
2. Work
• Tasks - hard to identify, can only define on a high level. According to Ziv et al., software engineering has a large and uncertain solution space, meaning that there are multiple software implementation possibilities for a given goal, in addition to unpredictable behaviour of components and systems [ZRK97].
• Activities - it is very hard to refine high level task descriptions into low level technical activities. Specification is not possible. Humphrey [Hum95] gives a reason for this with his requirements uncer-tainty principle: “For a new software system, the requirements will not be completely known until after the users have used it.”. This is also supported by the view of Ziv et al.: modeling real world problems in software, implies that the uncertainty of the model in question are also reflected in the results [ZRK97].
3. Productivity - becomes relevant after learning what tasks and activities are needed to achieve the goal. Ideally, in the situation where there is no uncertainty anymore, maximising capacity of the team means maximising value creation. Moreover, the faster the work can be done, the more value can be produced. 4. Value - can be difficult to define, because it is challenging to determine upfront what users of the software
5. Skills - can be difficult to assess. Uncertainty in the problem and solution domain can pose challenges that reveal insufficient skill in the people doing the work. Those challenges also allow those people to learn how to overcome that challenge, which increases their skill [JSH14].
Going into this work process where there is uncertainty involves discovering what works and what does not work. This can be illustrated by the process of writing a thesis. The goal is clear: write a thesis about subject X. Then a couple of tasks need to be identified, where one of them would be literature study. However, it is difficult to determine how big this task is, how long it would take and what activities exactly need to be done. Still, at some point an uncertain search query needs to be executed, which may lead to useful literature or not.
2.5
Learning
Overcoming the complexities derived from uncertainty involves learning, both in a trial-and-error process as well as taking new information to adjust actions and behaviours [Gra04,SL04]. Projects have uncertainty in the definitions of goal, work and value, resulting in changes in their definitions along the way. In order to proceed with the project, the new information of these changes need to be processed and used to creatively work towards satisfying the goal and providing value. This is a process of learning, in which resources learn from the new information, adjust their actions and repeat.
Learning happens on the individual level as well the organisational level, where individual knowledge is shared within the organisation so it becomes collective knowledge [Har03]. Learning happens on all aspects of the project: what is the goal, how can the goal be achieved, what value can be expected, and how much and what type of resources are needed to achieve the goal. An example of this is a project where due to complexity issues a new technology is developed by a project member. After project success and thereby discovering that the new technology makes certain organisational processes obsolete, the organisation could collectivise the learning of that individual and replace its old processes by the newly developed solution.
2.6
Practical software example
The effects of learning and uncertainty on the developed vocabulary will be demonstrated by using a practical software example. Suppose there is a small project with the goal of optimising a certain database query. The current data base query takes 6ms to complete, whereas the desired speed would need to be under 2ms in order for the application using the query not to be perceived as slow by the users (assume this is scientifically proven). Therefore, the value of this project is improved usability by reducing the query speed to under 2ms. How to proceed from here?
Since the solution space in software engineering is quite big, there are several tasks that could accomplish this goal:
• Let a team member attempt to optimise the current query code; • Consult a database expert;
• Let a team member conduct query profiling;
• Let a team member create the database query from scratch; • etc.
It is not clear which of these tasks will satisfy the goal, meaning there is uncertainty in the solution space for this problem. Therefore, a decision has to be made: which task seems most adequate.
First, the team assigns a team member to optimise the query. This decision introduces uncertainty, as the team do not know whether the team member is capable of improving the query to the extent of satisfying the goal. After a week of code analysis, the team learns that they do not possess the required skill to improve the query code. Given this information and comparing the available options, the most viable task is to hire an expert.
The expert performs a quick analysis of the situation and informs them that he has experienced this before and knows how to solve it. In turn the expert will have to define a number of activities he has to execute, while not knowing for sure they will actually lead to a query speed of 2ms. Suppose the expert starts with a certain
activity, because it has helped him many times before, such as rewriting the database query. Moreover, suppose this takes him a lot of hours, much longer than initially estimated, resulting in the team growing impatient. After some pressure from the team the expert claims he finished the task: he managed to reduce the query speed, but only lowering it from 6ms to 5ms. In addition, he came up with a caching solution that reduces the frequency of executing this query.
At this point, a lot of time and money is spent on a possible solution for this goal. Both the goal and desired value were known, but it was unclear which task offered the right solution, and which activities were needed. The effort was insufficient to satisfy the project goal, as the query still takes longer than 2ms to execute. However, despite not achieving the goal, the solution of the expert still provided value as the added value of the project was improved usability for the users by reducing slow responses from the application using that query. By creating the caching solution, the response time of the application improved, resulting in improved usability and thus providing value for the users.
2.7
Conceptual Model
A conceptual model was developed to explain how the earlier introduced concepts relate to each other. This model frames the thinking process and gives direction to literature study. The model depicts project entities, together with their relations and moderators. Based on the model, an organisational strategy for preventing resource scarcity in software projects is analysed in the next chapter.
Figure 2.3 Conceptual model of Expected and Realised Work and Value.
The model in figure 2.3 shows how Work is determined from Goal, how Resources are determined from Work and how their effort (Resources doing Work) is utilised to create value, while distinguishing between expectation and reality. In other words, there are Resources (number of people), whose effort is used to perform the Work in order to create Value. The Goal of the project determines what Work is defined for the project. Ideally, the result of the Work effort should yield the expected Value. However, this is not the case in software projects.
As explained before, inherent uncertainty can cause problems in the (quality of the) definitions of Goal, Work and expected Value. Also the effectivity of allocated Resources is uncertain, which can turn out to be lower than
expected due to variance in individual Skill, Motivation and Commitment. The project team needs to learn how to overcome the problems that can occur, which can result in changes in needed Resources or changes in the definitions of Goal, Work or Value. The process of overcoming these problems is symbolised by Learning. The amount of Learning in a project can lead to large differences in values of expected Work and realised Work, and expected Value and realised Value.
III
|
Preventing vs Utilising Resource Scarcity
“To learn gives you power to influence events” - Neil deGrasse Tyson
A
c c o r d i n g t o Van Egmond, a lot of problems in software projects are ultimately caused by organisationsstarting up more projects than they can handle [VE14]. These problems are interrelated and often cause each other in a chain of events. The starting point of this chain is an unbalanced situation between work and capacity, which is created by starting up more projects than the organisation can simultaneously work on and finish successfully. What is more, Van Egmond states that problems in one project have an impact and cause problems in other projects in the organisation.3.1
Advantages of Prevention
Doing work does not always lead to the desired outcome in the desired way, even if the same work is repeated. For example, a certain type of project could take a month at one time and four months at another time. Waste, waiting and chaos are factors that get in the way of achieving the desired result. Having a too high work load only aggravates these issues.
The situation expressed by the following table will be used to explain why too much work leads to problems and reduces overall goal completion. Suppose an organisation currently runs three projects with Goals 1, 2 and 3, while having 9 capacity available. Work needed for each goal is expressed in capacity, meaning goal 1 would require 2 capacity to complete the work.
Goal Work 1 2 2 3 3 6 Capacity 9
Table 3.1 Example of three projects with the Work defined in capacity and the available organisational Capacity.
Figure 3.1 Snapshot of the conceptual model concerning the situation displayed in table 3.1.
Figure 3.1 shows the relevant part of the conceptual model for the situation described in table 3.1. For each project, the work is defined based on the project goal. In turn, the needed resources are determined based on the work definition of a project. In this example, the total amount of expected resources for the three projects is 11, which exceeds the organisational capacity by two.
Waste
Say the organisation chooses to start all three projects and assigns one capacity (one resource, named Peter) to Goal 1, two capacity to Goal 2 (James and Kevin), and the remaining 6 to Goal 3. Peter is committed to Goal 1,
Goal Work Capacityassi gned
1 2 1
2 3 2
3 6 6
Table 3.2 The organisation decides to do all projects simultaneously.
but needs help from James and Kevin to complete his work. However, James and Kevin are not available, because they are committed to Goal 2. Therefore, Peter cannot complete his work and does not deliver the goal in time.
Figure 3.2 Snapshot of the conceptual model concerning waste.
In this situation, which is also depicted in the figure above, Peter is wasted. He was already allocated to a project, but his effort did not deliver his goal, nor could he be used to work on another goal. Committing this resource to Goal 1 is thus a costly waste.
Waste is committing capacity that does not achieve the goal.
Waiting
Continuing the previous scenario, James and Kevin are working on goal 2. At some point they encounter a complex problem they cannot solve. They need an expert to solve it, yet no expert is available, the organisation is already stretched thin as it is. James and Kevin cannot proceed and therefore have to wait till an expert becomes available and solves their problem.
The time spent waiting by these two is not used to work and therefore also wasteful and costly. Waiting is committing capacity that temporarily cannot work (more).
Chaos
After a while, the organisation realises project 2 is not advancing. However, this project has the highest priority to the company, therefore a decision is made to involve a crisis manager and concentrate efforts to complete the project within the deadline, leading to the following situation: Since this project is in crisis mode, an attempt is
Goal Work Expected 1 2 2 3 3 6 Realised 2 3 Capacity 9av ai l abl e 8assi gned
Table 3.3 The organisation puts all its efforts on completing project 2.
made to add a lot of resources to the project in a really short time span, which greatly increases overhead cost. Resources new to the project have to be trained, coordination efforts have to be ramped up, communications errors and coding errors due to lack of understanding create more problems, etc. This highly concentrated effort might manage to get the job done just before the deadline, although at much higher cost than anticipated.
Chaos follows from adding extra resources and increasing effort close to the deadline to reach the goal.
Reserves
The consequence of this situation is that for the next round of projects, project managers will try to safeguard their projects by adding reserves to their projects: requiring more capacity than needed. Using the example from 3.1 it could lead to this:
Goal Work 1 4 2 7 3 9 Capacity 9
Table 3.4 Reserve capacity added to the projects.
Adding reserves to a project increases waiting, as not everyone assigned to the project has something to work on, which adds unnecessary costs.
Reserves is allocation of more capacity than estimated.
3.1.1
Balancing Work to Capacity
Taking the above mentioned situation into account, the organisation would fare better by only doing project 2 and 3, where the total work can be assigned to the available capacity. The idea is limiting the amount of work to complete more goals in a given time span and thereby preventing resource scarcity, as can be seen in the following table.
Goal Work Expected 2 3 3 6 Realised 2 3 3 6 Capacity 9av ai l abl e 3assi gned 6assi gned
Table 3.5 The organisation decides to discard project 1 and focus on 2 and 3.
Now that the two projects have the resources they need, they can progress without suffering from the earlier described problems and can come to completion at a steady pace. Kanban literature supports this thinking [And12]. Work should be limited to what (task) can be done now, without distractions or dependencies, thereby preventing waste. Steadily completing tasks in this fashion leads to achievement of a goal in a sustainable pace, without having chaos or needing reserves.
3.2
Will Prevention really Prevent Waste, Waiting and Chaos
Balancing work to capacity by limiting active projects might seem to be a good strategy for an organisation looking to complete multiple goals in a given time frame. However, it requires knowing exactly how much capacity is needed for a goal, in order to make the best distributions of the available capacity. Furthermore, the organisation has to make a decision about which projects to pursue and which to discard, which means that the organisation needs know upfront which projects are the most valuable. The strategy leans very heavily on planning.
Uncertainty
In the previous chapter however, it is explained that software engineering has inherent uncertainty and that projects involve a lot of learning. Work cannot be specified, it is not clear what tasks and activities are really needed for the goal and how long these will take.
What is more, because completing a goal in software engineering involves learning during the project: it is not clear upfront how much value a project will have and what it takes to get there. The situation at the start of a project looks different from the situation at the end of a project. Therefore, when dealing with projects, a distinction has to be made in expectation and realisation. A goal has expected work, capacity and value, but different realised work, capacity and value.
Projects have Expected and Realised representations for work, capacity and value.
Waiting and Chaos
Balancing work to capacity means that all the resources are assigned to projects. These projects still face un-certainty, meaning that unforeseen events could occur. Examples of this are encountering a complex problem preventing a task to complete or discovering that a task requires much more work than expected.
Such events could require additional or specific resources to mitigate or solve the problem. The problem here however is that no other resources are available, since all resources were allocated in the beginning. This means that under this strategy ‘waiting’ can still occur.
What is more, Van Egmond’s theory of balancing work to capacity by limiting the number of active projects is aimed at completing more projects. The idea is that organisations decide to start projects only when they are convinced that there are enough resources and the project can be completed. But to be able to decide if a project is worthwhile to start and finish, a company has to invest in research and analysis to determine whether a project
can be started. This means that the preparation time of a project increases. It also implies that the projects that are active must complete, with sunk cost fallacy driving this thought. This means that resources could be kept working on a project that leverages little value. Moreover, whenever problems occur that induce waiting, it can be very problematic for the progress of the project. Since the project has to complete, there is a high risk of chaos in projects affected by unforeseen problems.
3.3
A Different Approach: Utilising Resource Scarcity
Ultimately, it is more important for organisations to maximize realised value through their projects, as projects are a means, not an end. It is better to do the right projects to produce value, instead of simply more. This means that a project goal can and should be changed if it means more value can be delivered.
Taking uncertainty into account, it is not clear what a project’s true value, work and thus needed capacity is at the start. Furthermore, there is not enough information available initially about which projects will prove achievable and more importantly, most valuable. Therefore, organisations should adopt a strategy that focuses on identifying and completing projects that yield the most realised value.
Capitalising on Uncertainty
In economics theory, Trigeorgis states uncertainty can be used in strategic resource allocation [Tri96]. It is possible to benefit from uncertainty by mapping the investment decision to a real option; more specifically a call option. A call option is a right - not the obligation - to invest at a later point in time. In this context, investing means allocating resources. This means that in the future a decision can be made to invest more resources, thereby committing to the initial investment.
By delaying the investment decision, a benefit from waiting can be gained, because more information comes available as time passes by. This encompasses both information about external factors as well as information about the internal process. In the context of software projects, an external factor could be a change in client demands, whereas internal process information refers to learning which solution yields a good result.
Start All Projects
Organisations can use the real option framework in a strategy to maximise realised value. Using this strategy, an organisation should start prospective valuable projects, having just enough capacity to start each project, while keeping some resources on stand-by that will be needed at a later point in time. Here, stand-by refers to unallocated resources, as can be seen in the following figure.
Figure 3.3 Snapshot of the conceptual model concerning unallocated resources.
Not assigning the resources on stand-by gives the organisation flexibility to use them as soon as they are needed. Using the previous example would give the following situation:
Time Goal Work Capacityassi gned Stand-by
t = 0
1 2 1
3
2 3 2
3 6 3
Choose When Necessary
Having started all the projects, the organisation should review and evaluate the projects at set time intervals and use the learned information for making decisions for each project. For example at t = 1, the projects are reviewed and it can be seen that for one goal, work exceeds capacity. This is a good moment to review the decisions made for this this goal, regarding expected value and assigned capacity. This point in time gives the organisation more information to make decisions with, such as changing work expectations. In turn, this could lead to the organisation deciding not to add capacity to the project, but rather determine what the assigned capacity could realise in terms of value.
Constantly reviewing the projects with new information gives a better ground for deciding which project to put an emphasis on. For example, it could turn out that Goal 1 proves very valuable at t = 2. In the previous strategy, this project would be discarded, while the organisation could decide to discard project 3 at t = 2, because the work turns out to be much more than expected, and the project therefore would be too costly.
Time Goal Work Capacityassi gned Stand-by
t = 2 1 1 1 1
2 7 7
Table 3.7 At t = 2 Goal 3 is discarded, while Goal 2 received more capacity.
Work Smarter not Harder
When focusing on creating value, decisions can be made differently regarding work. Generally speaking it is praised to work harder, in spirit of getting more work done. Nevertheless, Parkinson’s law explains that if there are more resources available there will be more work [Par83]. This means that there will always be more work, even if people are working harder.
However, doing more work does not automatically mean that more value is created. Considering that for Goal 1 it becomes clear at t = 1 that more resources are needed, a decision can be made not to add capacity to complete the work, which would mean working harder to meet the goal before the deadline. Instead, a completely different but more valuable solution could be pursued. This means that in light of emphasising value creation it is important to work smarter, not harder.
Efficiency over Team Potential
The Value Maximisation strategy benefits from scarce resource allocation by delaying the decision to commit to a project. Additionally, resource scarcity forces the project manager to think about how the available resources can be used, allowing the manager to make decisions that prove valuable. Moreover, project managers could achieve more than expected based on efficient use of the available resources. The reason for this is extensively discussed in the following chapter in which the value maximisation theory is grounded in literature.
As a side note, the idea of efficiency over team potential also applies to sports. Efficiency over team potential is supported by the study of Espita-Escuer and García-Cebrián, in which they evaluated the performance of football teams in the Spanish League [EEGC06]. They found that the final league position of a team relies on efficient use of resources rather than team potential.
3.4
Summary
Van Egmond’s theory argues for upfront decisions, whereas the value maximisation strategy tries to gather information along the way and delays making decisions. Furthermore, the two strategies differ on their view of resource scarcity. The first sees it at a problem that should be prevented, whereas the second accepts it is inevitable and utilises it to spur creativity towards value creation.
The strategies also disagree on the effects of resource scarcity and resource abundance. The workload - capacity balancing strategy finds that scarce allocation leads to problems, chaos, losing sight on the project and even
stopping the project. Also, problems in one project often cause problems in other projects, or cause disruptions elsewhere in the organisation. By contrast, abundant allocation of resources should prevent problems, which leads to better projects and allows more projects to complete. In comparison, the value maximisation proposition argues that scarce allocation leads to smarter decisions that allow more effective value creation. Abundant allocation on the other hand leads to loafing, waste, expensive projects and a lack of focus.
Although there are arguments to be made in favor of Van Egmond’s theory, the inherent uncertainty in software engineering also presents downsides to this theory. This challenges his assertion that problems in software projects stem from starting too many projects. Moreover, it raises the question whether software projects can even be planned well in light of uncertainty. Investing more effort in planning is an option, but could come with too much cost.
Inherent uncertainty will likely result in unexpected problems or changes while running a project. It is impor-tant to assess what options are available to the project manager to mitigate or solve these unexpected occurrences.
IV
|
Grounding the Theory in Literature
“The defining factor for success is never resources, it is resourcefulness” - Anthony Robbins
W
h y c a n t h e r e be achieved more with less resources? This chapter tries to answer that question by meansof literature study. Furthermore, literature findings regarding differences in perspective from the two theories regarding resource performance are discussed.4.1
Stress and Performance
A difference between the value maximisation theory and the project limitation theory is the relationship between resources and workload. Van Egmond advises with his project limitation theory against increased workload, be-cause it increases stress [MPM86] and introduces problems [VE14]. Value maximisation theory on the other hand, involves increased workload per resource in order to be more effective. The effect of stress on performance due to increased workload is therefore an important consideration and has been researched from an organisational psychology and behaviour perspective.
According to Sullivan and Bhagat, stress in human resources can affect important organisational processes and results, such as job performance [SB92]. Muse, Harris and Field conducted a literary review where they reviewed the negative linear, positive linear and inverted-U theory of stress and job performance [MHF03].
The negative linear theory states that any form of stress costs time, focus and energy, thereby reducing job performance [MHF03]. Moreover, stress affects individuals both mentally and physically, which reduces the ability to take in important information and subsequently hinders performance. By contrast, positive linear theory explains that stress creates a challenge for the resource, which results in a higher performance of the resource in the attempting of overcoming the challenge. The inverted-U theory combines the negative and positive linear theories: increasing stress has good effects, but at a certain point the effects turn bad. Stress is therefore necessary to stimulate resources to reach their optimal performance. More importantly, it is key to be at the center point of the inverted-U shape - lower levels allow laziness, whereas higher levels comes at a cost to performance.
Surprisingly, little empirical evidence exists for the inverted-U theory, with most results supporting the negative linear theory [MHF03]. However, Muse et al. argued that this can be explained due to biases in the research design. These studies focused on measuring the over-stressed state and therefore found results supporting the negative linear theory. The under-stressed state was not (adequately) measured. Moreover, the inverted-U is supported in activation/arousal research, which measures the relationship between arousal and performance. Although Naatanen ([Nää73] in [MHF03]) argued that stress and arousal are not similar, Ivancevich and Matteson ([IM80] in [MHF03]) suggested that stress equals demand and that with moderate levels of demand people perform best. This means that in a situation of under-stress, performance is suboptimal.
The positive linear theory - for which there is a moderate amount of evidence - frames stress as a challenge [MHF03]. This is supported by Boswell et al., who explained that when stress is associated with responsibility and workload, resources experience greater work challenge [BOBL04]. From the perspective of the inverted-U theory stress starts out as good (challenge) and turns bad after passing the maximum of the invert-U curve, suggesting that stress is a level of demand ([Sel82] in [LPL05]). However, researchers have found that stress is two-dimensional, as it can be (experienced as) a hindrance (negative) or a challenge (positive), meaning that stress is a type of demand [BOBL04,LPL05,DZE02].
Scholars also studied the effect of the stress types on performance and motivation [LPL05,DZE02,Tay81]. For instance, Taylor found that there is a causal relationship between challenge and performance. What is more, the
findings show the significance of motivation on the relationship between challenge and performance [Tay81]. Taylor suggested that when professionals are given challenging tasks, their increased performance results in positive feedback and increased perceived skill competence and job satisfaction, followed by increased perfor-mance standards for the next assignment, which is beneficial to the development of the professional in the long run. This is supported by the work of Drach-Zahavy and Erez, who described stress as either a challenge or a threat and researched its effects on the goal-performance relationship [DZE02]. They found consistently better performance when stress was experienced as challenging as opposed to threatening. In addition, Lepine et al. found that hindrance stressors had direct negative effects on performance, combined with indirect effects such as increased strain and lowered motivation [LPL05]. In turn, challenge stressors had direct positive impact on performance and indirectly served as offset to strain while increasing motivation.
Literature explains that stress is either appraised as a challenge or hindrance [LPL05,DZE02]. Lepine et al. explained that high workload, time pressure, work scope and high responsibility are demands that are appraised as challenge stressors, as these demands have the potential to increase mastery, personal growth and future gains [LPL05]. Moreover, appraisal affects the emotional state of the individual, which influences how a stressor is dealt with. By appraising a stressor as challenging, meaning an opportunity for increased growth or gains, positive emotions are elicited and an active problem-solving mindset is applied with increased effort. What is more, Lepine et al. theorise that this is in accordance with expectancy theory, which involves (1) beliefs about the relationship between the amount of effort needed to cope with a demand and the probability of successfully satisfying the demand, and (2) beliefs about the relationship between successfully meeting the demand and the value it provides. Hence, challenge stressors should provide high motivation as it is likely that there exists a positive relationship between a high amount of effort spent dealing with a demand, the probability of successfully meeting the demand, and providing value with the end result. For example, in the event of a time pressure demand, it is likely that a professional believes a deadline can be met by increased effort and upon success rewards will be received such as a sense of accomplishment and recognition from the professional environment.
In any event, resources have no control over these stressors, be it challenging or threatening. However, Lepine et al. suggested that managers are important in this regard and can influence resource motivation and perfor-mance by reducing hindrance stressors, while increasing challenge stressors [LPL05]. The influence of software project managers in this context is also supported by Drach-Zahavy and Erez, as they found that in changing environments, which require high adaptation, a combination of challenging work and difficult goals resulted in the best performance in a series of tasks, compared to no goals or ’do-your-best’ goals combined with challenging work [DZE02].
Managers can increase resource motivation and performance by increasing challenge stressors and reducing hindrance stressors.
4.2
Adaptive Performance
As explained in the previous chapter, software development has inherent uncertainty, which makes software projects extra demanding. It is difficult for the resources to deal with changes and demands stemming from uncertainty and complexity, while trying to perform to the best of their capability. Such demanding environments ask for adaptive performance of the resources. This applies especially in the case of the value maximisation theory, as the environment and conditions can and will change often, which means that adaptive performance from resources is vital. Moreover, research has found it to be a distinguishable component of overall job performance [CVEAV10].
Charbonnier-Voyrin et al. described adaptive performance as the ability to (1) work creatively and learn ef-fectively, (2) manage and cope with situations of stress, adversity, unpredictability and emergency, and (3) find one’s place in socially and culturally diverse environments [CVEAV10]. In other words, the ability of proficiently adjusting behaviour to meet the demands of the new environment, context or situation [CVEAV10]. Schoss et al. described adaptive performance as “the extent to which individuals are responsive to changes in task requirements and in their work environments,” which means acquiring, improving and applying competencies and behaviour to deal with anticipated or present changes [SWV12]. This is partially supported by Jundt et al., however they limit their interpretation of adaptive performance to task-related changes.
Tae Young and Williams studied adaptive performance at both the individual and team level and found that team adaptive performance can be represented as the accumulation of individual adaptive performance [HW08]. This means that when individuals showed high levels of adaptability, this level extended to the team’s level of adaptation. Furthermore, teams with positive learning climates showed higher adaptive performance. This means that teams that are open to new ideas, tolerant of mistakes in the learning process and expect high performance, allowed the team members to reach a high level of adaptive performance individually.
In an environment of task-related changes, adaptive performance of resources is needed to sustain or increase towards high performance [SWV12]. However, not all adaptation efforts automatically lead to high performance. Shoss et al. argued that the ability to direct full attention to the adaptation process is necessary for successful adaptation, which is a prerequisite for sustained or higher performance [SWV12]. They furthermore identified two moderators which influence the ability or capacity to direct attention to the adaptation process, namely conscientiousness and organisational politics. Conscientiousness is associated with being detail oriented and highly organised, having determination for achievement and having high problem-solving capability. High levels of conscientiousness therefore facilitate successful adaptation. Organisational politics however, is associated with more ambiguity and uncertainty in organisational goals, decisions and processes. Shoss et al. argued that high levels of organisational politics are a distraction, thereby negatively impacting attention for adaptation, and require more attention from the individual to process the information it produces. Their findings support a positive relationship between adaptive performance and conscientiousness, having found a positive relationship between adaptive performance and task performance in the situation of high levels of conscientiousness and high level of organisational politics. Surprisingly, they did not find a positive relationship between adaptive performance and task performance in a situation of high level of conscientiousness and low level of organisational politics. They explain this by the self-reliance and independence of conscientious individuals, as they will continue their old ways of performing tasks unless they are really challenged. Therefore, Shoss et al. argued that managers are tasked with instructing, motivating and - more importantly - challenging resources towards adaptive performance behaviours, while keeping organisational politics from draining their energy and focus.
By instructing, motivating and challenging resources towards adaptive performance behaviours and protect-ing them from energy drainprotect-ing organisational politics, manager can influence resources towards sustained or increased performance in highly dynamic environments.
4.3
Leadership
Adaptive performance needs to be driven by leadership. According to Charbonnier et al., transformational leadership encompasses the components related to behaviours that enable adaptive performance [CVEAV10]. Transformational leadership describes four dimensions, namely (1) idealised influence: leaders can represent a trustworthy role model and deliver more effort in new and complex situations, (2) inspirational motivation: leaders can establish, articulate and communicate a strong future vision, which instigates and empowers indi-viduals to take on change initiatives in the organisation, (3) intellectual stimulation: leaders can stimulate and encourage individuals to question beliefs and assumptions, take risks, approach problems from another point of view and look for new solutions, and (4) individualised consideration: by treating followers individually, leaders can help them to focus on their individual strengths and to cope with and overcome moments of stress. Through these dimensions, transformational leaders can help individuals to transcend self-interests, deal with change and perform beyond expectations ([Bas85] in [CVEAV10]).
Transformational leaders improve self-esteem of resources by providing an attractive vision, considering indi-vidual needs, and stimulating the use of one’s full creative potential [CVEAV10]. Such leadership allows resources to build inner strength, which combined with inner self-esteem prepares them for dealing with demanding sit-uations. This forms the foundation of adaptive performance as the inner strength and self-esteem allows the individual to remain positive and focused when dealing with stressful and changing situations. Furthermore, transformational leadership not only leads to increased performance by transforming individual attitudes, it creates a climate at the team level which holds a shared understanding of the leader’s influence, challenging vision, intellectual stimulation and individual consideration [CVEAV10].
transformational leadership and adaptive performance [CVEAV10]. A climate for innovation holds norms and practices, which stimulate learning, generating ideas and flexibility, combined with organisationally encouraged and rewarded values of taking charge and adapting to changes. A climate for innovation thereby communicates that it is a strategic priority for the organisation that individuals develop themselves to contribute creatively and adaptively to the organisational goal. Moreover, through its four dimensions, transformational leadership encourages individuals to build inner strength and resources for contributing to the organisational goal. Further-more, Charbonnier et al. suggested that by creatively applying their inner resources, individuals should perceive alignment of the actions of transformational leaders with their sense of self-engagement. This suggests that in-dividuals benefit from the influence of transformational leadership when exposed to a climate for innovation. What is more, given a strong climate for innovation, transformational leaders have a high probability of enhanc-ing exploratory and critical thinkenhanc-ing processes, encouragenhanc-ing out-of-the-box thinkenhanc-ing and supportenhanc-ing efforts of adaptation [CVEAV10].
Charbonnier et al. researched the relationship between individual adaptive performance and (1) individual perceptions of transformational leadership and (2) team-level transformational leadership climate. In addition, they hypothesised a positive effect of a climate for innovation on the relationship between transformational leadership and individual adaptive performance [CVEAV10]. Their findings support a positive relationship be-tween individual perception of transformational leadership and individual adaptive performance, as well as a moderating effect of a climate for innovation on this relationship. Furthermore, a positive relationship was found between team-level transformational climate and individual adaptive performance.
Managers can have a positive impact on adaptive performance by practicing transformational leadership. At the individual level, individual consideration and intellectual stimulation enable learning and adjusting to changing environments. Moreover, by also creating a climate for innovation (encouraged by the organisation), managers can increase individual and team adaptability. Paired with the creation of challenge stressors, managers can enhance adaptive performance at the individual and the team level and subsequently enhance individual performance beyond expectations.
Managers can positively impact adaptive performance of resources through transformational leadership: creating a climate for innovation, as well as practicing individual consideration and intellectual stimulation of their resources.
4.4
Decision Making
Another aspect of the value maximisation theory is late decision making. Whereas the project limitation theory advocates committing early with respect to resources and work, value maximisation theory delays such decisions as much as possible. Literature supports delayed commitment and decisions in the context of uncertainty and product development [SWL99,Thi88,LM06,SCJ97,FS+05,WLCSI12,Rot09].
Thimbleby explained that it is a human tendency to commit early to decisions when faced with a (new) problem, as it decreases the number of subproblems and associated complexity [Thi88]. Moreover, he argued that this is especially the case in software development where design decisions are often made early-on using imperfect information and are often more accidental rather than conscious in nature. Regarding product development, Sobek et al. wrote that in traditional design there is a tendency to narrow down to one solution and modifying this solution until the design goals are met [SWL99]. This is also called the point-based approach, where teams quickly choose the best option from several possibilities to reduce complexity and limit development cost [FS+
05]. What is more, Verganti stated that decisions made in the early phase of product development are not likely to change in later stages of the project, and therefore have the highest influence on the outcome and performance of a project [Ver99].
Because early decisions are of such influence, they should account for changes and opportunities that arise in later phases [Ver99]. In other words, future information needs to be anticipated in order to avoid low quality early decisions, which result in late and costly changes and suboptimal product quality. However, Thimbleby explained that with early decision making there is uncertainty about the information used for the decision and the outcome of that decision [Thi88]. MacCormack et al. added to this, by stating that in uncertain and dynamic environments - which applies to software engineering - significant changes can occur both externally (stakeholder or market
needs) and internally (resource availability or used technology). Future information cannot really be anticipated in uncertain and dynamic environments such as software product development.
By contrast, delaying decisions and commitment is advocated for such an environment. Thimbleby stated that delaying commitment enables developing new insight [Thi88]. Ward et al. found that Toyota managers delay decision making by adopting a set based approach in which they wait to acquire better and more information for eliminating solutions, thereby slowly converging to the solution that suits best at the final stage of development [WLCSI12,SWL99,Rot09]. What is more, MacCormack et al. found that better performing projects in uncertain and dynamic environments are associated with flexibility to respond to new information in later phases of development, hence delay of commitment [MVI01].
As explained earlier, the economic theory of call-options is applicable to the decision making process regarding recourses in software development projects because of the inherent uncertainty. Sullivan et al. used the real-option economic framework as an analogy and theoretical foundation for software decision making [SCJ97]. In this context, decisions are characterised by uncertainty about future outcome, irreversibility and postponing ability [SCJ97]. When for example a manager makes a decision to add two more developers to a project, he does not know how much (more) value will be produced by their addition; even though their work can be discarded, the added cost of their man-hours are irreversible; a manager has the opportunity to try something else with his existing team and can still add these resources at a later point in time, when there will be more information available. Making decisions can come at the cost of having the opportunity in the future to make a better decision. Therefore, under uncertainty of information, direct cost and realised value, managers are encouraged to delay decisions [SCJ97].
However, simply delaying decisions in projects is not a guarantee for higher project performance or product quality and can come at higher cost. Toyota, for example, uses information learned during the development process to increase or modify requirements that allow them to eliminate alternative solutions, essentially making smaller decisions that provide them new information [SWL99]. Moreover, Sullivan et al. explained that uncer-tainty does not equate postponing decisions, instead an early small investment decision can be made to partially reduce uncertainty [SCJ97]. What is more, in his research about anticipation versus flexibility by doing case studies of 18 companies in various sectors, Verganti found that structural flexibility (i.e. reactionary decision mak-ing) is not sufficient to deal with uncertainty and instead advocates planned flexibility. Planned flexibility entails the capability of identifying specific critical areas in a project and early planning and triggering of reactionary measures to mitigate problems in those areas [Ver99]. In other words, critical decisions should be identified early on and be postponed to when they are necessary.
Software project managers could benefit from delaying commitment and decisions regarding resources and work. The main point is to deal with uncertainty of information and outcome. They should do so carefully and at all times weigh the uncertainty and quality of the information presented at the time of decision making.
4.5
Project Termination Effects
As explained earlier, it depends on the context created by the organisation and the project manager whether resources can reach high performance in projects. It is hard to establish this in highly dynamic environments. Moreover, the value maximisation theory also involves taking decisions about terminating projects when new information shows they are unfeasible or not valuable. Such termination decisions also have their effect on motivation, energy and future performance of the resources that were attached to the terminated projects [BBP96]. Research on project termination effects on human resources is rather limited, but has been emerging in recent years [BBP96,MHW12,SC09,SPW11,SPWW14].
The significance of meaning and value of one’s work is demonstrated by the work of Ariely et al., in which they compared work with meaning to work without meaning [AKP08]. They argued that labour is viewed meaningful when that labour is firstly recognized and secondly perceived as purposeful. They performed two experiments. In the first, participants had to perform a task on paper and received payment once a condition was met. After completion, the participants were asked if they were willing to repeat the task, albeit for a lower payment. This kept repeating until the participant decided to stop. Additionally, participants were placed in one of three conditions:
(1) participants were instructed to write their name on the paper and after completion of the task the experimenter would inspect their results and file the paper; (2) participants were not instructed to write their name and after completion their paper would be placed on a high stack of papers immediately; (3) again no instruction for writing their name and after completion of the task, the paper was shredded immediately. The results showed that participants in the first condition had the highest productivity and were willing to continue the longest. The second experiment involved participants building a bionic Lego figure with instructions provided and receiving a payment upon completion. Again, the participants were asked if they were willing to repeat the task, but each time for lower payments. This time there were two conditions: (1) the finished figure was placed on the table and the participant was given a new Lego set for repeating the task; (2) the finished figure was disassembled immediately upon completion and the same set was used for subsequent tasks. The results of this experiment showed that participants in the first (meaningful) condition built significantly more figures than those in the second condition. Ariely et al. showed that meaningful and purposeful work resulted in higher productivity and commitment [AKP08].
What is more, Norton et al. showed how much humans value their own work after completion through their research on what is called ’the IKEA effect’ [NMA12]. They found that humans have a “fundamental need for effectance - the ability to successfully produce desired outcomes in one’s environment.” What is more, successful task completion is perceived necessary for meeting one’s goal to feel competent and in control, hence having positive impact. By contrast, failure to complete tasks has negative effects and emotions. In their experiment, they asked participants to build three different products (IKEA boxes, origami figures and Lego figures) and place a monetary value on their completed task and completed tasks of others. Additionally there were conditions with varying degrees of completion: (1) complete, from start to finish; (2) incomplete, pre-built; (3) incomplete, immediate destruction after completion. The results showed that participants valued their own creations significantly higher than those of others, even when presented with higher quality (expert) creations. Furthermore, effort without completion (both incomplete conditions) did not result in higher valuation.
In the context of software projects, it is thus also important that the work performed by the resources is both meaningful and purposeful and is completed successfully. However, an organisation might find grounds on a strategic level to decide for termination of a project, which subsequently affects the resources. Balachandra et al. wrote that termination decisions can demoralise resources and hurt their future career opportunities as a result of being part of a failed project [BBP96].
Shepherd et al. also researched the impact of project termination decisions on project resources [SC09,SPW11, SPWW14]. When something of importance is lost, negative emotions such as grief are experienced [Arc99]. In the value maximisation theory, resources are setup to heavily invest their time and energy into the project, pushing themselves beyond expectation. Norton et al. showed much people value their own work [NMA12]. A termination would mean loss of the hours and energy spent. Shepherd et al. also argued that such loss is experienced in the case of project termination, resulting in negative feelings associated with failure, such as anger, personal pain, sadness, worry, anxiety, frustration and depression [SPW11].
This sense of failure may cause resources to doubt the meaning of their work and decrease their affective commitment to the organisation, i.e. the degree with which they identify and are involved with the organisation and are willing to invest personal resources to accomplish organisational goals, thereby also affecting future individual and organisational performance [SPW11]. Furthermore, termination induced negative emotions may cause resources to (1) overestimate the probability of negative outcomes, while underestimating the probability of positive outcomes in future projects; (2) become more risk adverse; (3) show attitude and behaviour that decreases trust and commitment in the organisation and increases risk of turnover and work slowdowns; (4) be obstructed to learning from failure [SC09]. Moreover, negative emotions negatively impacts information processing capability by narrowing attention and hinders creative thinking and learning [SPWW14].
Therefore, negative emotions following project termination can adversely impact organisational learning and future organisational performance. Especially in the case where termination decisions are taken with a short term focus only (e.g. financial) and disregard of emotional consequences of the decision, individual and organisational learning is obstructed, hurting growth of organisational knowledge and therefore organisation itself in the long term.
There are however several ways to cope with project termination decisions, such that negative effects are reduced and learning is encouraged and facilitated. Firstly, Shepherd and Cardon theorized and found that resources showing a high level of self-compassion (through self-kindness and mindfulness) are better equipped to learn from failure after experiencing negative emotions induced by project termination [SC09]. This is because self-compassion decreases engagement of ego-defending behaviour, which obstructs learning by denying personal
