Increased globalisation and market volatility put pressure on organisations to become more exible and explore new technologies and operational domains, so that projects are becoming more complex, with increasing uncertainty and risk. Complex project management is challenging for both traditional and agile approaches: traditional techniques may be left behind by unrecognised environmental change in a volatile context, while in a stable environment, agile may require too expensive interaction with the client. One area of growing interest is how traditional and agile may combine to increase the chance of project success. Yet how to strike a balance between the two remains poorly understood. In this position paper, we propose a model for complex socio-technical projects related to risk arising from volatility, that tries to explain the balance of agile and traditional. The model introduces the concept of drift rate as a measure of volatility, with the impact of drift related to loss of development resource, risk accumulation as a function of resource expenditure and drift rate, and validation the means to manage that risk.
Organisations must adapt to their changing business environment to remain pro table, competitive and able to meet their strategic goals. In large organisations, projects are the instrument of choice for such adaptations, each project addressing speci c organisational socio-technical problems. Increased globalisation and market volatility are putting pressure on organisations to become more exible and explore new technologies and operational domains, so that projects are becoming more complex, with increasing uncertainty and risk.
There are many sources of complexity and uncertainty. From a technical
perspective, they stem from the combination, interactions and inter-dependencies
of technologies and the pace of technical change [
At a fundamental level, all project management approaches, whether
traditional (`plan-driven') or `agile,' seek to control uncertainty and manage risk,
while making best use of resources. Complex projects are problematic for both
approaches: environment volatility is a challenge for plan-driven ones, technical
complexity for agile ones, and knowledge complexity for both. While often
considered as antithetic, plan-driven and agile practices are increasingly combined
in practice, particularly in software development, in an ad hoc manner to reap
their bene ts, with various degrees of success [
[
The ultimate aim of the work is to equip organisations with the tools to
understand better the nature of their problems and tailor their project
management practices to their needs and culture. This position paper is a step towards
this aim: it seeks to explicate risk characteristics of project management
approaches when interpreted as problem solving processes, through the lens of
a design theoretic framework for complex problem solving, called Problem
Oriented Engineering [
The Project Management Institute's PMBOK de nes risk as \an uncertain event
or condition that, if it occurs, has a positive or negative e ect on one or more
project objectives such as scope, schedule, cost, or quality" [
In Cleden's view [
One of our objectives is to explicate how traditional and agile project management deal with risk and uncertainty in complex projects.
Ahern et al. [
In line with this thinking, in our research, we look at complex project
management through the lens of Problem Oriented Engineering (POE, see [
POE is concerned both with di erent types of knowledge, spanning problem and solution spaces, and with stakeholders with a role in the problem solving process. In essence, a POE problem is a recognised (real-world) need in context, whose solution satis es it. Arriving at a solution is a process in which need, context and solution are progressively `explored' and `validated.' During exploration, learning takes place so that stakeholders come together to create, organise and exchange knowledge, which reduces knowledge complexity, while validation records stakeholders' satisfaction on the outcome of exploration, reducing uncertainty and contributing to coherence.
Explorations take time and e ort, so that expenditure and project risk is accumulated during such activities. Through validation, explorers transfer risk to validating stakeholders. When validation fails, backtracking to a previous state, including project start, may be the outcome.
In its idealised form, such a process is captured by the pattern in Figure 2. The pattern relates fundamental activities and actors and is not a prescriptive model | a process may be linear, iterative, spiral, fractal, etc.
Validation
Problem exploration (problem explorers)
Solution exploration (solution explorers)
Validation
In summary, as caputured by the PPP, complex project management is a problem solving endeavour to design solutions to organisational problems (need in context), and in which knowledge and social complexity are tackled through problem and solution explorations and validations, reducing uncertainty and mitigating risk.
Our conjecture is that PPP and its underlying concepts provide a fruitful theoretical framework in which to analyse risk characteristics of traditional and agile project management approaches when interpreted as problem solving processes. In the next section we put this idea to the test by proposing a model for project risk arising from problem (need in context) volatility. 4
Traditional project management approaches expect projects to be completely planned in advance, with their execution merely a process of implementation. As a consequence, resources are committed to a chosen solution early in the project lifecycle. Even if we were to discount knowledge complexity | which prevents both problem and solution from being completely knowable at the onset | such a commitment is particularly risky in the presence of problem volatility, due, for example, to rapid market or technological change (context volatility) or stakeholder con icts (need volatility). If one were to take the same approach to archery, one would identify a target and aim, close ones eyes, pull back the string and let an arrow go. In the case that the target is static, such an approach might be appropriate. But what in the case of a moving target? The arrow will land where the original target was, not where it has moved to.
Thus, in traditional approaches, xing a solution choice early incurs the risk that the problem will have moved as a product of the volatility of the organisation's problems (need in context): the more volatile the problem, the higher the likelihood that a delivered solution will `miss' its target, i.e., the delivered solution does not satisfy the need in context. Instead, we must track the target as it `moves': this is where validation has a role to play.
To understand `problem drift', we propose the `problem drift model' illustrated in Figure 3: { the vertical axis represents `problem drift', which is a measure of divergence from the problem the project was set up to solve and that which is in the real world, as a result of problem volatility; { the horizontal axis represents resource use (equivalently, the passage of time) from most recent validation (initially project front-end); { we assume an `acceptable drift range' (the shaded area), where the divergence is not su cient to invalidate development of the solution; { the `drift rates' lines indicate the degree of problem volatility: from high (V1), i.e., the environment changes very quickly, to low (V3), where it changes more slowly.
Marked on the horizontal axis is a `validation point,' which is the point where validation against the problem is sought on some validation artefact from stakeholders. Three situations are considered: i) in a situation of low drift (V3), drift has occurred but the validation artefact can still be validated; ii) when medium drift (V2), drift leads to a marginal call on the boundary between acceptable and unacceptable drift; iii) when high drift (V1), the validation artefact cannot be validated and some or all development resource is lost: based on the knowledge gained, a previous project state may be revisited or, in the extreme, the project is abandoned.
itrf D
V1:Highdriftrate
unacceptable drift V2: medium drift rate marginal drift
V3: Low drift rate acceptable drift validation point
Under this model, the impact of problem drift relates to lost development
resource, and risk accumulation is then a function of resource expenditure and
drift rate, with validation the means to manage risk. This is consistent with
empirical evidence [
Seen this way, we may interpret the role of validation in various project
management approaches. At the extremes:
{ in extreme plan-driven methods, such as Royce's posited Waterfall model
[
One might ask, if agile copes with all drift rates, why not eschew plan-driven methods altogether? Indeed, this view might be the source of the popular view that all processes should be agile. Our model also explains why this is not the case, however: validation requires time and e ort, and so consumes resources, diverting them from development. As a result, agile processes `pay' for their management of risk through potentially expensive validation.
There is therefore a balance to be struck between agile and plan-driven: the model suggests that the optimal balance is to validate at, or just before, the point of marginal drift (V2). To do this a number of things are required: i) the measurement of problem volatility; ii) the notion of acceptable drift; and iii) ways of combining traditional and agile methods to support the optimal balance. 5
Complex project management is challenging for both traditional and agile approaches: traditional techniques may be left behind by unrecognised environmental change in a volatile context, while in a stable environment, agile may require too expensive interaction with the client. One area of growing interest is how traditional and agile may combine to increase the chance of project success. Yet how to strike a balance between the two remains poorly understood.
In this position paper, we have proposed a model for complex socio-technical
projects related to risk arising from problem volatility, that tries to explain
the balance of agile and traditional. The model is located within the Problem
Oriented Engineering (POE) framework of the second and third authors [
A di erent characterisation of tradition versus agile is given in [
The drift model proposed presupposes that drift can be measured and predicted. The objective of future research will be to explore if these measurement and prediction are feasible and how to implement them. For instance, it is plausible that measuring how problem descriptions change over time is one possible proxy measure for context volatility. However, more sophisticated notions should also be considered.
Supposing that our drift model works, the question arises as to the extent we
can optimally combine agile with traditional processes. This would require some
hybrid process architecture to be developed. The second and third authors have
already taken preliminary steps in the analysis of the agile/plan-driven mix in
the context of software projects in [
Finally, in our model we have focused on problem volatility and process
activity, irrespective of organisational culture, which is an acknowledged key success
factor for agility [