ArticlePDF Available

Is There an Underlying Theory of Software Project Management? (A critique of the transformational and normative views of project management)

Authors:

Abstract and Figures

Traditional project management methods are based on scientific principles that would be considered "normal science," but lacks any theoretical basis for this approach. [31, 32, 63] These principles make use of linear stepwise refinement of the project management processes based on a planning-asmanagement paradigm. Plans made in this paradigm and adjusted by linear feedback methods cannot cope with the multiple interacting and continuously changing technology and market forces.
Content may be subject to copyright.
1
/
22
Is There an Underlying Theory of Software Project Management?
Version 5.0, 29 June 2015
Glen B. Alleman
Niwot, Colorado
glen.alleman@niwotridge.com
Abstract: Traditional project management methods are based on scientific
principles considered “normal science,” but lack a theoretical basis for this
approach. [34, 35, 66] These principles make use of linear stepwise
refinement of the project management processes using a planningas
management paradigm. Plans made in this paradigm are adjusted by
linear feedback methods. These plans cannot cope with the multiple
interacting and continuously changing technology and market forces. They
behave as a linear, deterministic, ClosedLoop control system.
Using a ClosedLoop adaptive control system, parallels can be drawn
between this approach and agile project management methods. From
these, a comparison can be made between project management practices
and the tenants of agile development processes in terms of feedback
control and emergent solutions with a control system capable of adjusting
to the changes brought about by change of the dynamics of the process,
disturbances, or some other cause not established in the original plan.
This paper suggests adaptive control theory may be better suited as a
model for project management in a rapidly changing, dynamically
evolving network of statistical processes than traditional linear approaches
when managing in the presence of uncertainty.
2
/
22
1 Introduction
Since the early days of the software technology industry, managing development
projects have been fraught with uncertainty and risk. While the technical content of
products and the methods used to build them have changed over time, the
fundamental issues that determine the success or failure of a project has remained
constant.
Our traditional control system for managing projects is not well suited to respond to
project changes we encounter in software development. In software systems we don’t
see many changes coming due to the emergent requirements of the development
paradigm, including impacts to technical and programmatic work from:
§ Nonlinear disturbances
§ Changes in the operating conditions
§ Nonstationary disturbances
The success rate of software development has been underwhelming in the presence of
these conditions when applying traditional methods in complex development software
development project environments. [29] The traditional, linear, stepwise approach
has its roots in project management methods of the 1970’s. It was clear then and has
become cleared today, that this approach to managing projects is inappropriate in
many domains. [63, 64] What is missing in the project management literature is the
answer to the question is there an underlying theory of project management
appropriate for complex, Software Intensive Systems development projects? [73] A
secondary question is can a theory be constructed that is consistent with adaptive
control system and agile processes currently in use in manufacturing, science,
engineering, economics, biology, and ecology?
The approach described here looks to theories in other domains that match the
behavioral aspects of software project management. The theory of Control Systems is
one choice. Performance references, control loops, and stochastic processes all have
similar paradigms in project management. In addition the theory of complex adaptive
systems and adaptive controls for those systems has a similar paradigm in the “agile”
software development domain.
3
/
22
The development of complex systems requires substantial elements of creativity and
innovation as well as needed frameworks of engineering and governance. Predicting
the outcome of the development effort, given a fixed set of resources and time is
difficult. Add to this, external market forces, incomplete or illformed requirements,
and changing stakeholder’s need creates three questions for consideration:
§ What methods are appropriate for the management of these efforts?
§ What theoretical aspects of project management can be applied to this project
environment?
§ What gaps exist in current project management methods that can be closed to
increase the probability of success in the presence of uncertainty?
1.1 Project Management Theory
The current project management literature describes project management in terms of initiating,
planning, executing, monitoring and controlling, and closing of the project. This literature often
assumes project management takes place within the paradigm of managementasplanning.
In this paradigm there are causal connections between the actions of management and
the outcomes of the project. This view of project management regards projects as
instruments with which to achieve a goal rather than as individual organizations in
their own right.
1
Feedback from this planning process is based on an after the fact
variance detection. As a feedback control system, gaps in the feedback include: delays
used to correct the plans and execution before the deviation grows too large, adaptive
planning through adaptive feedback loops, and feedforward controls to direct the
execution based on inputs about future needs of the stakeholders.
In the literature, project management methods are reduced to stable, technical, and
linear processes.
2
The impact on the project from external forces or from problems
within the project is given little attention. It is assumed in this traditional model that
“change” is an undesirable thing, when in fact change in the business systems world is
not only natural it is desirable. The conflict between “managing in the presence of
1
The origins in industrial society can explain why much project management theory assumes that projects take
place within a single organization. This basic assumption is out of step with post-industrial society’s joint
ventures, and strategic collaborations.
2
Linear project management models are sometimes referred to as waterfall models. In these models it is assumed
that each phase of the project is completed in a fixed sequence, followed by the next logical phase. In the Agile
methods the linearity still exists, since the statistical processes and the resulting probabilistic outcomes are
formally addressed in the management control system.
4
/
22
change” and “managing change” by attempting to control it is the source of many of
the gaps between traditional project management and agile project management.
One approach to defining a theory of project management can be found in [46]. It is
conjectured that a wellfunctioning bureaucracy aided by scientific planning tools can
efficiently deal with a project through these “normalscience” methods. This
approach assumes projects are carried out under conditions of complete rationality.
3
It also assumes that projects are repetitive, with their requirements and stakeholder
needs built existing knowledge.
The majority of software development projects are not conducted under conditions of
rationality. Software projects are not repetitive, stable, statistically stationary, or
linear. They are unique, driven by unstable requirements, technology, and market
forces, and contain many nonlinear activities and stochastic processes. Technical
development is complex, the exact business and technical outcome is difficult to plan.
The processes used to manage the outcome may chaotic. Projects are often subjected
to forces outside the control of the project manager, engineers, and stakeholders.
More importantly, the development and deployment of complex technical projects
creates a nonlinear feedback loop between the development and the deployment
process. Once the project outcomes are deployed, the users have new and sometimes
disruptive requirements once they know and understand how the delivered system
works.
A framework for examining this situation can be found in a similar approach in the
management of systems engineering activities. [60]
Figure 1 presents an overview of the elements and dimensions of project
management. The “control system” involved in project management is not shown,
since this is a static view of the elements and their interactions. The important aspect
of Figure 1 is the connection between the components of the problem domain and the
solution domain. As the problem grows, the linear non-adaptive approaches to
managing work in the presence of uncertainty have lower probability of success.
3
All rational action embodies some sort of precautionary principle. What kind of harm can be averted? What
kinds of cost are willing to be incurred by the stakeholders? In the rational context, risks can be preidentified,
production rates are known, defects can be statistically analyzed, and requirements can be elicited up front.
5
/
22
Figure 1 Dimensions of Complex Project Management independent of the actual control
system used to manage the project. As complexity increases the non-linear dynamics of the
project and its management demand methods other than traditional planning and control.
Statistical process control can address the issues using for adaptive behavior using feed forward
development.
1.2 Managing the in Presence of Uncertainty
All project work is performed in the presence of uncertainty. Traditional project
management and even Agile project management has no means to maintain stability
of project performance in the presence of this uncertainty. When a disruptive event
occurs, the project performance is also disrupted and the project must be re-planned to
correct the source of the disruption.
Information is needed to manage under these conditions. Two issues must be
addressed. Information must be provided by the observed outcomes of the project.
This is a state estimation problem. The second is the formulation of the stochastic
control problem.
Three aspects of project performance management using any control system,
traditional, agile, or adaptive must provide guidance for:
§ Estimation linear estimation, non-linear information, and uncertain information
Program Office Scope of Interest
Balanced
Scorecard
Classification
Project Attributes
Scope (S)
Progress (P)
Behavior (B)
Program
Domain
Complexity
Programs
(Participative)
Systems
(Rational)
Projects
(Normative)
Tools
State
Transformation
Management
Value
Generation
Techniques
Flow
Management
S:Single
P:Time Boxed
B:Linear
S:Multidiscipline
P:Interdependent
B: Scheduled
S:Enterprise
P:Evolving
B:Non-Linear
Incremental
Stretch
BHAG*
Systems
Programs
Projects
T
o
o
l
s
,
T
e
c
h
n
i
q
u
e
s
,
a
n
d
M
a
n
a
g
e
m
e
n
t
Techniques & Mgmnt
Tools
PERT
GANTT
WBS
Historical
and
Projective
Estimating
Tools
Balanced
Scorecard,
Monte Carlo
Simulations
Enterprise Project Management Platform
Earned Value Analysis Management
* Big Hairy Audacious Goals
1
3
2
Increasing Tools Complexity
Increasing Problem Domain Complexity
Increasing Project Attribute Complexity
1
Single purpose projects
2
Multiple Single purpose
projects
3
Enterprise Wide
Multiple or Single
purpose projects
6
/
22
§ Identification of the parameters that impact the performance of the project.
§ Control of these parameters to maintain the desired project performance.
The normative advice provided by traditional project management bodies of
knowledge planning, execution, and control forms a ClosedLoop linear system.
This advice is usually based on rules that specify which choices will maximize
benefits to the participants. Normative theory suggests a project is a series of
sequentially related activities.
Beyond this normative approach, project management is a set of multiple interacting
interdependent random activities behaving in a nonlinear and adaptive manner. This
is an operational definition of a Complex adaptive systems (CAS) that can be applied
to modeling project management activities. Adaptive control systems offer a simpler
model without the complex and intractable mathematics of CAS. The distinctions
between traditional and adaptive management can be summarized in Figure 2:
Traditional Methods
Adaptive Methods
Planning drives results
Results drive planning
Delivery focused on planned results
Delivery focused on derived results
Defined process steps
Selfadapting process steps
Figure 2 Distinctions between Traditional and Adaptive Project Management methods. The
application of these methods is dependent on the complexity of the project and the dynamic
behaviors of those complexities.
1.3 A Focus on Information Technology Project Management
Software Intensive Systems (SIS)
4
projects traditionally use formal management
processes for the acquisition or development, deployment, and operation of the
system that emphasizes planning in depth. This approach organizes work into phases
separated by decision points. Supporters of this approach emphasize that changes
made early in the project can be less expensive than changes made late in the project.
SIS can be found in a variety of business and technical domains
4
A software-intensive system is any system where software contributes essential influences to the design,
construction, deployment, and evolution of the system as a whole. [from ISO/IEC/IEEE 42010:2011].
7
/
22
§ Business information systems the US Government is one of the large
consumers of ERP system, finance systems, logistics systems, personnel and
payrolls
§ Network reliant systems this is the traditional command and control systems
found in industry and government, where data is exchanged between physical
disparate systems, with large amounts of data used to assist humans in awareness
and decision making processes.
§ Infrastructure systems enterprise systems of interconnected business,
embedded, or other systems. This infrastructure provides equipment and
capability needed for integrated complex systems to function properly.
§ Embedded systems systems that interact with the physical, through sensors,
displays and human command and control for control applications in industry,
equipment, and products used to control other systems.
The embedded systems market is approximately 100 times larger than the desktop software
market. Hardly any new product reaches the market without embedded systems any more. The
number of embedded systems in a product ranges from one to tens in consumer products and
to hundreds in large professional systems.
Embedded systems are an important business domain for the application of the adaptive project
control paradigm based on Agile development processes, including capabilities planning,
programmatic and technical estimating, risk management and program performance
management. [Embedded Systems Roadmap 2002, published by the Technology Foundation of
the Netherlands (STW)]
In the past, when waterfall
5
is used as the approach to SIS, the framework contains
several erroneous assumptions that negatively impact SIS projects:
§ Planning the assumption it is possible to produce a plan so that its
implementation is merely a matter of executing a defined set of tasks in a
predefined order.
§ Plans for complex projects rarely turn out to be good enough for the plans to
remain intact through out the project life cycle.
5
The term waterfall has been used many times as a strawman by the agile community. In fact very few pure waterfall
projects exist today. This is not to say there are not abuses of the concept of waterfall sequential development
based on the simple algorithm REPEAT [Design, Code, Test] UNTIL Money = 0. In practice,
development and deployment processes based on incremental and iterative methodologies are the norm. The
literature contains numerous references and guidelines to this iterative project management approach dating back
to the 1980’s [63].
8
/
22
§ Continuous replanning, readjusting of priorities, and reanalyzing the
consequences of these changes is common practice.
§ Unanticipated problems are the norm rather than the exception.
§ Change It is not possible to protect against late changes.
§ All businesses face late changing competitive environments.
§ The window of business opportunity opens and closes at the whim of the
market, not the direction of the project manager.
§ Stability Management usually wants a plan to which it can commit. By making
this commitment, they give up the ability to take advantage of fortuitous
developments in the business and technology environment [67].
§ In a financial setting this is the option value of the decision.
§ Deferring decisions to take advantage of new information and new
opportunities is rarely taken into account on IT projects [68].
1.4 Adaptive Control Systems and Agile Methods
In adaptive control systems dynamic characteristics are not constant because of changes to the
parameters and changes to the environment. The effects of small changes on the dynamic
characteristics may be attenuated in a feedback control system. If the changes are significant a
system must be in place with the ability to adapt. The adaption implies self-adjustment or self-
modifying in accordance with the unpredictable changes in the conditions. In adaptive systems,
the dynamic characteristics must be identified so the control parameters can be adjusted to
maintain optimum performance. Such systems accommodate the uncertainties found in all
project work, especially agile development where requirements are emerging. [53]
"To adapt,” means to change a behavior to conform to new circumstances. Intuitively,
an adaptive controller is a control system that can modify its behavior in response to
changes in the dynamics of the process and the character of the disturbances. [30]
Agile processes emphasis both the rapid and flexible adaptation to changes in the
process, the product, and the development environment [4]. This is a very general
definition and therefore not very useful without some specific context which will be
developed below. Even agile processes are driven by linear, non-statistical algorithms
and are missing the statistical aspects of the underlying processes. To be adaptive the
control loop needs to
§ Provide control for non-linear processes
§ Adaptively tuned the control algorithm with no interruption to the controlled
process.
9
/
22
§ Be capable of fast response to changing conditions.
Before establishing this context, agile methods include three major attributes, they
are:
§ Incremental and Evolutionary allowing adaptation to both internal and external
events.
§ Modular and Lean allowing components of the process to come and go
depending on specific needs if the participants and stakeholders.
§ Time Based built on iterative and concurrent work cycles.
§ SelfOrganizing in the sense that normative guides have little to offer in terms
of structure and control. Agile methods rely primarily on heuristics and
participative processes rather than normative and rational methods and
guidelines.
1.5 Project Management as a “Control System”
The general requirements for a control system start with it being absolutely stable. This is a
primary requirement. In additional to this absolute stability, the control system must have a
reasonable relative stability. That is the speed of response must be reasonably fast. The control
system must be capable of reducing errors to near zero or some small tolerable value. The
requirements of reasonable relative stability and steady-state accuracy are usually incompatible.
In designing the control system it is necessary to make the most effective compromise between
these two requirements. [53]
The vocabulary of the project management [17] is similar to that found in control
systems [41, 50]. With these terms, it will be clear that Project Management can be
modeled as a control system. With this modeling comes the ability to assess the
components of project management, the control system that provide feedback and
corrective action for maintaining the performance of the project.
Most importantly for this paper, the basis for introducing the notion of Adaptive
controls to manage projects in the presence of uncertainty and emergent behavior,
often found in Agile software development domains.
10
/
22
These terms include:
Project Management Process
Control System
Monitoringtrack, review, and regulate
the progress and performance of the
project; identify any areas in which
changes to the plan are required and
initiate the corresponding changes. [71]
Reference signalan independent
variable (or set of variables) that defines
the desired output. The error signal is the
arithmetic difference between the
reference signal and the output signal.
6
Evaluatingan assessment of the
project’s progress to plan using some
normative unit of measure, usually
money, or time.
Plant or processis a continuous
operation or development marked by a
series of gradual changes that success
one another in a relatively fixed way and
lead toward a particular result. An
artificial or voluntary, progressively
continuing operation that consists of a
series of controlled actions or movements
systematically directed toward a
particular result or end.
Controlmonitors and measures
progress against plan to identify
variances and provide corrective action,
generating feedback to the decision
making process.
Controllerwhich uses feedback, in the
presence of disturbances, tends to reduce
the difference between the output of the
system and the reference input.
Figure 3 Project Management and Control Systems Vocabulary. Making these connections is
the basis of applying adaptive controls in the project management domain.
2 Project Management as a Control System
Control systems play an important role in engineering, science, economics, and
biological systems. They also play an important role is creating models of other
general systems, either as models of these systems or as metaphors of the models of
these systems. [8].
Early control systems were based on linear feedback models. As the entities being
controlled became more complex, the classical control theory, which dealt with single
input and single output systems, became less useful. Multiple input and output
systems now dominate control systems theory and practice. Recently adaptive and
6
In the case of a simple temperature controller, the reference signal is the desired temperature. The error signal is
the difference between the desired temperature and the current temperature. If this error is positive, then the
process is instructed to lower the temperature. If this error is negative, then the process is instructed to raise the
temperature. This is a very simple example, but will serve to illustrate the point that project management has
similar terms and concepts as ClosedLoop controller.
11
/
22
optimal control systems have been developed. Applications of modern control theory
to nonphysical fields are also the norm. Biology, economics, sociology and other
dynamic systems are also common practice. Complex Adaptive Systems is a popular
topic today.
Constructing a connection between control systems, especially adaptive control
systems and project management is the goal of this section.
2.1 Basic Problems in Control System Design
Before moving forward some comparisons between control systems and project
management systems will be helpful. Project management is a Close Loop Control
system.
A closed-loop control process assures that a system performs within control limits. In
closed-loop control, the system's output is fed back directly to change the system's
inputs. The way in which a thermostat works with a furnace to control room
temperature is an example of ClosedLoop control. Closed loop control starts with an
explicit objective (e.g., the desired room temperature), a measure of the status of the
system against that objective system (e.g., the difference between the actual and
desired room temperatures), and a mechanism for adjusting the system's inputs to
correct the difference and meet the objective (e.g., turning the furnace on or off).
Process Control
Process
A natural and progressively continuing
operation or development marker by a
series of gradual changes that succeed
one another in a relatively fixed way and
lead toward a particular result.
Systems
A combination of components that act
together and perform a certain objective.
Disturbance
A signal, which tends to adversely affect
the value of the output of a system.
Feedback
control
An operation in the presence of
disturbances tends to reduce the
difference between the output of a system
and the reference input.
12
/
22
Process Control
Damping
Damping is an influence within or upon
an oscillatory system that has the effect
of reducing, restricting or preventing its
oscillations.
Feedback
control system
A system designed to maintain a
prescribed relationship between the
output and the reference input by
comparing these and using the difference
as a means of control.
Closed loop
Control
Is one in which the output signal has
direct impact on the control action, as
shown in Figure 5. In a ClosedLoop
system the error signal, which is the
difference between the input and the
feedback, is fed to the controller to
reduce the error and bring the output of
the system to a desired value.
Open loop
Control
Is one in which the output signal has no
direct impact on the control action, as
shown in Figure 5. In an open loop
system the output is neither measured nor
fed back for comparison with the input.
For each reference input there is a fixed
operating condition.
performance.
Adaptive
control system
Method of control used to adapt to a
controlled system where parameters vary,
or are initially uncertain.
Performance
index
Is a quantitative measure of the
performance, measuring the deviation
from the ideal performance. The
specification of the control signal over
the operating time is the Control Law.
Learning
control systems
Many openloop control systems can be
converted to closedloop control system
if a human operator is placed in the loop.
This operator compares inputs with
outputs and makes corrective actions
based on the resulting errors.
Figure 4 Attributes of Control Systems and Project Management Systems. Not all attributes
in control systems can be found in traditional project management systems. Moving project
management to be more like close loop adaptive control systems.
13
/
22
Figure 5 illustrates Open Loop and ClosedLoop control systems. Only the Close
Loop Control system is applicable to managing projects. Project management is a
Close Loop control system. Some production processes can be Open Loop control as
a monitoring and reporting process.
The Open Loop control process has little value for project management, but is the
basis of the Close Loop control process needed to make corrective actions in the
presence of variances in project performance.
Controller Process
Control
Signal
Input Output
Controller Process
Input
Output
Measuring
Element
Open Loop System
Closed Loop System
Control
Signal
Figure 5 Open and Closed Loop Systems. Both can be found in the project management
domain. But only the Close Loop control system can provide indicators of performance
variances needed to take corrective actions to maintain the needed activities to arrive on or
before the need date, at or below the planned cost, and with the needed capabilities.
2.1.1 General Requirements for a Control System
Any useful control system must satisfy the following conditions:
§ The first requirement of any control system is stability.
§ In addition to absolute stability, the control system must have relative stability,
that is the speed of response must be reasonably fast and must show reasonable
damping.
§ A control system must be capable of reducing errors to zero or to some small
tolerance level.
14
/
22
The requirement for relative stability and steadystate accuracy are actually
incompatible. The design of a control system becomes a tradeoff between these two
requirements.
2.1.2 Adaptive Control Systems
Adaptation implies the ability to selfadjust or selfmodify with unpredictable
changes in conditions of environment or structure. In an adaptive control system, the
dynamic characteristics must be identified at all times so that the controller
parameters can be adjusted in order to maintain optimal performance.
2.2 Basic Approach to Control Systems Design
One approach to the design of control systems, which will be useful here, is to use
block diagrams, which are pictorial representations of the functions performed by
each component of the system and the signals that flow between these components.
7
Figure 6 is a logical depiction of a ClosedLoop control system.
This system consists of two elements:
§ Block element is the symbol of the operation performed on the input signal to
produce the output signal. The notation inside the block is usually the transfer
function of the block given as the Laplace function.
§ Error detector produces an error signal,
( )
Es
, which is the difference between
the reference input,
( )
Rs
and the feedback signal,
( )
Cs
. The choice of the error
signal is very important. Any imperfections in the error signal will be reflected in
the performance of entire system.
7
For the moment the specific notation used in Figure 6 will be ignored, since the interest is in applying control
systems theory to project management. The “functions”
( )
Rs
,
( )
Es
, and
( )
Cs
, represent the reference,
error, and control signals respectively. These are functions of Laplace space rather than of time. For not familiar
with the Laplace transform it is defined as
( ) ( ) ( ) ( )
st st
f t F s e dt f t f t e dt
∞∞
−−
== =
⎡⎤ ⎡⎤
⎣⎦ ⎣⎦
∫∫
00
L
. By
transforming a time varying function to Laplace space it can be manipulated as an algebraic expression rather than
as a differential equation.
15
/
22
Input
Output
( )
Gs
( )
Cs
( )
Rs
( )
Es
+
Feedback
Figure 6 A Logical Depiction of a Closed Loop Control Systems. This paradigm can be
applied to project management systems. The error signal is the difference between planned
performance and actual performance. The system under control is the baselined IMS and it’s
BCWS
2.3 Adaptive Controls Design
Adaptive control is a specific type of control where the process is controlled in closed-loop, and
when: knowledge about the system characteristics are obtained on-line while the system 'is
operating. Based upon refreshed information obtained during normal operation, specific
interventions in the control loop arc made in order to fulfill the control goal. Interventions can
be various but mainly they can be categorized as interventions obtained by changing: the signals,
parameters, and structure
In most feedback systems, small deviations in parameters values from their design
values will not cause any problem in the normal operations of the system, provided
these parameters are inside the loop. If the process parameters vary widely because of
environmental changes, then the control system will exhibit unsatisfactory behaviors.
In some cases large variations in process parameters will cause instability in non
adaptive systems.
A simple definition of a adaptive control system is: a control system in which
continuous and automatic measurements of the dynamic characteristics of the process
are taken, comparisons are made with the desired dynamic characteristics, and
differences uses to adjust the system parameters usually the controller
characteristics or the generation of an actuating signal so as to maintain optimal
system performance, regardless of the environmental changes to the process.
16
/
22
Controller
Input
Output
Process
Decision
Id or PI
Measurement
+
Figure 7Adaptive Controller makes use of measurements and feedback adjustments from the
behaviors of the system in the presence of those measurements to adapt the control loop to the
emergent behavior of the system under control
To be called adaptive, some form of selforganizing features must exist. An adaptive
controller consists of the following three functions:
§ Identification of the dynamic characteristics of the process.
§ Decision making based on the identification of the process.
§ Modification or actuation based on the decisions made.
By performing these functions continuously, selforganization can take place to
compensate for unpredictable changes in the process.
2.3.1 System Behavior Identification
The dynamic characteristics of the process must be measured and identified
continuously. These measures should be accomplished through the effects produced
by the normal operation of the system. Identification may be made from normal
operating data or by the injection of test signals. Identification with normal data is
possible only when this data has adequate signal characteristics (bandwidth,
amplitude, etc.) for proper identification.
2.3.2 Decision Making In The Presence of Emergent Behaviors
Decisions are made on the basis of the process characteristics, which have an
identified or a computed performance index. Once the process has been identified, it
is compared with the optimal characteristics (or optimal performance), then a decision
made as to how the adjustable controller characteristics should be varied in order to
maintain optimal performance.
17
/
22
2.3.3 Modification Based on Decisions Made
Modification refers to the changes of control signals according to the results of the
identification and decision processes. There are two approaches to modifying controls
signals:
§ Controller parameter modification in which the controller parameters are
adjusted, to compensate fro changes in the process dynamics.
§ Control signal synthesis in which optimal control signals are synthesized based
on the transfer function, performance index, and desired transient response of the
process.
3 Project Management Theory as Control System Theory
With the control system theory established, let’s connect that theory with the needs of
software project management. This paper proposes the characteristics of software
development projects, especially agile software development, can be modeled using
adaptive control system theory.
3.1 Control Theory Summary
Control is a guiding a set of variables towards a common goal. Management Control
Theory may be seen as afterthefact control or beforethefact control. Control
theory, suggests that where consequences are easily monitored, afterthefact controls
are more effective. Where consequences are unique and hard to monitor, beforethe
fact control is appropriate.
4 Agile Project Management and Adaptive Control
What is needed now is some way to tie adaptive control theory to agile project
management. A simple approach is to compare the primary attributes of adaptive
control with agile PM methods.
Adaptive Control
Agile Project Management
Identification of the desired loop
performance.
What is the project performance needed to
arrive on time, on budget, with the needed
capabilities.
18
/
22
Adaptive Control
Agile Project Management
Decision Making
By assessing the planned outcomes against
with actual outcomes, decisions can be made
about the corrective actions needed to
maintain the planned performance.
Modification based on the decision made
With this assessment information, changes to
the work processes, work intact, technical
processes, and resources can be made to
maintain the planned performance.
5 A Framework for Adaptive Project Management Processes
Traditional project management assumes linear feedback loops, stability in work process, and
no disruptive changes to requirements. Software development projects rarely posses these
attributes.
One question is are the methods described in traditional PM frameworks appropriate
for Adaptive or Agile Project Management? One place to look for traditional
frameworks is the Project Management Institute’s Project Management Body of
Knowledge
®
.
First let’s look at the control block picture of the PMBOK’s functions. Figure 8
describes a simple view of PMBOK’s control elements.
Control
Execution
Output
Plan Plans
Change
Control
Performance Reports
Controller Process
Figure 8 PMBOK Control Blocks. There is one feedback loop and two inputs to the process
under control. In PMBOK the process is based on a Plan and changes to the Plan are
incorporated in the Plan.
5.1 Gaps In Traditional Project Management
In Figure 8 there several things missing when viewed from a control systems process.
19
/
22
§ There is no capacity for work reference signal the flow of control makes use of
performance reports to define the change control signal. These performance
reports have no reference signal by which create an “error” signal. The planned
outcomes are baselined and the actual value compared to produce an error signal.
But the planned values are not assessed for the needed capabilities and the actual
capabilities of the actual values. It is not sufficient to desire a performance
measure. This desired performance measures must actually be achievable. This
missing assessment what is our actual capacity for work, the achievable work
is not part of the traditional project management. For project management to be
successful, the capacity for work must be part of the adaptive control loop.
§ There are multiple control signals both plans and change control are used as a
control signal. Measuring variance from plan set point minus measured value,
and changes to the set point are part of the multiple control signals. The coupling
between these two control signals masks the individual contributions to the
control loop. Separating these signals needed to isolate the corrective actions in
the control loop.
§ The dynamics and transfer function of each process is not specified. This includes
the sample rate and the response rate of each process. The dynamics of the
systems under control and the loop gain for controlling this system are not
defined in the traditional management process.
5.2 Applying Adaptive Controls To Close These Gaps
«Put the practical parts of AMO’s paper here»
20
/
22
6 Bibliography
1. Alexander, Christopher, Notes on the Synthesis of Form, Harvard University
Press, 1964.
2. Alexander, Christopher, A Timeless Way of Building, Oxford University Press,
1979.
3. Agresti, New Paradigms for Software Development, IEEE Computer Society
Press, 1986.
4. Aoyama, Mikio, “Agile Software Process and Its Experience,” International
Conference on Software Engineering, 1998.
5. Ballard, Glenn, “The Last Planner System of Production Control,” thesis
submitted to the Faculty of Engineering, School of Engineering, University of
Birmingham, 2000.
6. Basili, Victor, “Iterative Enhancement: A Practical Technique for Software
Improvement,” IEEE Transactions on Software Engineering, 1(4), December
1975.
7. Bateman, T. S. and C. P. Zeithaml, Management: Function and Strategy, Irwin,
1990.
8. von Bertalanffy, Ludwig, General Systems Theory: Foundations, Development,
and Theory, George Braziller, 1976.
9. Boehm, Barry, “Getting Ready for Agile Methods, with Care,” IEEE Computer,
35(1), January 2002, pp. 6469.
10. Charette, Robert N., “LargeScale Project Management is Risk Management,”
IEEE Software, pp. 110117, July 1996.
11. Christensen, Mark J. and Richard H. Thayer, The Project Manager's Guide to
Software Engineering's Best Practices, Computer Society Press, 2002.
12. Cleland, David I., Project Management: Strategic Design and Implementations,
McGraw Hill, 1998.
13. Charette, Robert N., “LargeScale Project Management is Risk Management,
IEEE Software, pp. 110117, July 1996.
14. Cook, H. E., Product Management Value, Quality, Cost, Price, Profit and
Organization, Chapman & Hall, 1997.
15. Davis, Alan M., “Fifteen Principles of Software Engineering,” IEEE Software,
11(6), pp. 9496, November/December, 1994.
16. Dempster, Beth, “Science versus PostNormal Science,”
http://www.fes.uwaterloo.ca/u/mbldemps
17. Duncan, William, A Guide to the Project Management Body of Knowledge,
Project Management Institute, 2000.
18. Earl, Michael, Jeffery Sampler, and James Short, “Strategies for Reengineering:
Different ways of Initiating and Implementing Business Process Change,” Centre
for Research in Information Management, London Business School, 1995.
19. Earl, Michael, “Information Systems Strategy: Why Planning Techniques are
Never the Answer,” Centre for Research in Information Management, London
Business School, 1995.
20. Erdogmus, H., “Valuation Of Complex Options In Software Development,” First
Workshop on EconomicsDriven Software Engineering Research, EDSER–1,
May 17, 1999.
21. Flatto, Jerry, “The Role of Real Options in Valuing Information Technology
Projects,Association of Information Systems Conference, 1996.
22. Funtowicz, S. and J. Ravetz, “PostNormal Science: A New Science for New
Times,” Scientific European, pp. 9597, March 1992.
23. GeorgescuRoegen, Nicholas, The Entropy Laws and Economic Progress,
Harvard University, 1971.
24. Feng, Gang, Adaptive Control Systems, Newnes, 1999.
21
/
22
25. Foster, Jason, James Kay, and Peter Roe, “Teaching Complexity and Systems
Theory to Engineers,” 4
th
UICEE Annual Conference on Engineering Education,
7–10 February 2001.
26. Funtowicz, S. and Jerome R. Ravetz, “PostNormal Science: A New Science for
New Times,” Scientific European, pp. 95–97, March 1992. Also in Futures,
25(7), pp. 739751.
27. Funtowicz S, and Ravetz, “Post-Normal Science An Insight Now Maturing,
Futures, 31:641646, 1999.
28. Funtowicz S, and Jerome R. Ravetz, “Three Types of Risk Assessment and the
Emergence of PostNormal Science”, in Krimsky S, and Golding D (editors),
Social Theories of Risk, Westport CT, Greenwood. Pp. 251273, 1992.
29. Glass, Robert L., Software Runaways: Lessons Learned from Massive Software
Project Failures, Prentice Hall, 1998.
30. Adaptive Control Systems, 2
nd
Edition, Karl Johan Astrom and Bjorn
Wittenmark, Prentice Hall, 1992.
31. Giglioni, Giovanni B. “A Conspectus of Management Control Theory: 1900
1972, Academy of Management Journal, 17(2), June 1974.
32. Hallows, Jolyon E. Information Systems Project Management, AMACOM, 1997.
33. Harmsen, Frank, Ivo Lubbers, and Gerard Wijers, “SuccessDriven Selection of
Fragments for Situational Methods: The S3 Model,” Design Methodology
Research Group, Department of Computer Science, University of Twente.
34. Hofstade, Geert, “The Poverty of Management Control Philosophy,” Academy of
Management Review, July 1979, pp. 450461.
35. Howell, Greg and Lauri Koskela, “Reforming Project Management: The Role of
Lean Construction,Eighth Annual Conference of the International Group for
Lean Construction, (IGLC8), July 2000.
36. Jackson, M. C., “Towards Coherent Pluralism in Management Science,” Journal
of Operational Research, 50(1), pp. 1222, 1999.
37. Jackson, E. T., “Teaching Project Management for the 21
st
Century: Why it is
Important and What is New?” Carleton University, School Of Business
Administration, Ottawa, Ontario K1S 5B6, Canada.
38. Jones, Capers, “What it Means to be Best in Class,” Version 5, February 10,
1998.
39. Jones, Capers, Patterns of Software Systems Failure and Success, International
Thompson Computer Press, 1996.
40. Kogut, Bruce and Nalin Kulatilaka, “Strategy, Heuristics, and Real Options,” The
Oxford Handbook of Strategy (2001), Chapter 30, 2001.
41. Kogut, Bruce and Nalin Kulatilaka, “Strategy, Heuristics, and Real Options,” The
Oxford Handbook of Strategy (2001), Chapter 30, 2001.
42. Kogut, Bruce and Nalin Kulatilaka, “What is Critical Capability?” Reginald H.
Jones Center Working Paper, Wharton School, 1992.
43. Koskela, Lauri and Greg Howell, “Reforming Project Management: The Role of
Planning, Execution, and Controlling,” Ninth Annual Conference of the
International Group for Lean Construction, (IGLC9), 2001.
44. Koskela, Lauri, We need a theory of construction, BerkeleyStanford CE&M
Workshop: Defining a Research Agenda for AEC Process/Product Development
in 2000 and Beyond. Stanford, 26 28 Aug. 1999. Berkeley. University of
California; Stanford University, 1999.
45. Kuhn, T. S., Structure of Scientific Revolutions, Chicago University Press, 1962.
46. Lewis, Marianne, M. Ann Welsh, Gordon E. Dehler, and Stephen G. Green,
“Product Development Tensions: Exploring Contrasting Styles of Project
Management,” Academy of Management, 2002.
47. Luks, F., “PostNormal Science and the Rhetoric of Inquiry: Deconstruction
Normal Science?”, Futures, 31(7), pp. 705719, 1999.
48. May, Lorin J., “Major Causes of Software Failures,” Crosstalk, July 1998.
22
/
22
49. Maciarello, Joseph A. and Calvin J. Kirby, Management Control Systems: Using
Adaptive Systems at Attain Control, 2nd Edition, Prentice Hall 1994.
50. McCarthy, Dan, “Normal Science and PostNormal Inquiry,” University of
Waterloo, Waterloo Ontario.
51. Morris, Peter W. G., “Researching the Unanswered Questions of Project
Management,” Project Management Research at the turn of the Millennium,
Proceedings of PMI Research Conference, June 2000, pp. 87101.
52. Nelles, Oliver, Nonlinear Systems Identification: From Classical Approaches to
Neural Networks and Fuzzy Models, Springer Verlag, 2000.
53. Ogata, Katsuhiko, Modern Control Engineering, 4
th
Edition, Prentice Hall, 2002.
54. Osterweil, Leon J., “Software Processes are Software Too,” Proceedings of the
9th International Conference on Software Engineering (ICSE 1987), pp. 213,
March 1987, Monterey, CA.
55. Osterweil, Leon J., “Software Processes Are Software Too, Revisited,”
Proceedings of the 19th International Conference on Software Engineering
(ICSE 1997), pp. 540548, May 1997, Boston, MA.
56. Pajares, Frank, “The Structure of Scientific Revolutions,” Outline and Study
Guide, Emory University, http://www.emory.edu/EDUCATION/mfp/Kuhn.html.
57. Potters, Marc, et. al. “Financial Markets as Adaptive Ecosystems,” May 31, 2001.
arXiv:condmat/9609172.
58. Ravetz, Jerome R., “What is PostNormal Science,Futures, 31(7), pp. 647653,
1999.
59. Ravetz, Jerome R. and Silvio Funtowicz, “PostNormal Science: An Insight now
Maturing,” Futures, 31(7), pp. 641646, 1999.
60. Rechtin, System Architecture: 2
nd
Edition, CRC Press, 2000.
61. Rockart, J. F. and C. V. Bullen, “A Primer on Critical Success Factors,” Center
for Information Systems Research, Working Paper No. 69, Sloan School of
Management, MIT, 1981.
62. Rockart, J. F., M. Earl, and J. Roos, “Eight Imperatives for the New IT
Organization,” Sloan Management Review, Fall, 1996, pp. 4356.
63. Royce, Winston W., “Managing the Development of Large Scale Software
Systems,” Proceedings of IEEE WESCON, pp. 19, August 1970.
64. Royce, Walker, Software Project Management, Addison Wesley, 1998.
65. Selfridge, Oliver G. (editor), Adaptive Control of IllDefined Systems, Plenum
Publishing, 1984.
66. Shenhar, A. J. and D. Dvir, “Toward a Typological Theory of Project
Management,” Research Policy, 25(4), pp. 607, 1996.
67. Sullivan, Kevin, P. Chalasani, S. Jha, and V. Sazawal, “Software Design as an
Investment Activity: A Real Options Perspective,” in Real Options and Business
Strategy: Applications to DecisionMaking, edited by Lenos Trigeorgis, Rick
Books, 1999.
68. Szulanski, Gabriel, “Unpacking Stickiness: An Empirical Investigation of the
Barriers to Transfer Best Practices Inside the Firm,” INSEAD Study, Academy of
Management Best Paper Proceedings, pp. 437441, November 1995.
69. Tao, Gang, Adaptive Control Design and Analysis, John Wiley & Sons, 2003.
70. Thorburn, W. M. “The Myth of Occam's Razor,” Mind 27:345353, 1918.
71. Project Management Body of Knowledge, 5
th
Edition, Project Management
Institute.
72. Project Based Organizations as Complex Adaptive Systems, Carlos Eduardo
Yamasaki Sato, Dario E.A. Dergint, Kazuo Hatakeyama
73. ISO/IEC/IEEE 42010, Systems and Software Engineering Architectural
Description, 2001-12-01
... Exploratory research intended to displace the existing dated theory has been limited, with a few notable exceptions such as the application of Adaptive Control Theory (Alleman, 2002) and a growing body of literature on the application, often using simulation techniques, of Complex Systems (Benbya and McKelvey, 2006; Morris, 2002; Williams, 2005). Exploratory practice-led research is all but absent in the IS project management literature. ...
... For example, as early as 1997, there were over 1,000 methodologies in use by the IS community (Fitzgerald, 1998). Exploratory research intended to displace the existing dated theory has been limited, with a few notable exceptions such as the application of Adaptive Control Theory (Alleman, 2002) and a growing body of literature on the application, often using simulation techniques, of Complex Systems (Benbya and McKelvey, 2006; Morris, 2002; Williams, 2005). Exploratory practice-led research is all but absent in the IS project management literature. ...
Article
Full-text available
This paper reports on a high potential and under-utilised approach to developing theory to improve IS project performance, a significant and persistent problem for the IS discipline. It presents a multi-disciplinary approach to exploratory research, which is oriented towards solving problems in practice by developing new theory or adapting extant theory to a new milieu. This research approach is based on 'looking for a gap in practice and finding the theory in the gap'. It presents examples from a program of research that has provided a number of theories to improve IS project management performance. It shows that the IS field may require multiple theories to support the management of projects rather than a single theory of project management.
... Exploratory research intended to displace the existing dated theory has been limited, with a few notable exceptions such as the application of Adaptive Control Theory (Alleman, 2002) and a growing body of literature on the application, often using simulation techniques, of Complex Systems (Benbya and McKelvey, 2006;Morris, 2002;Williams, 2005). Exploratory practice-led research is all but absent in the IS project management literature. ...
... But for example, project management has origins rooted in practice. An overall theory is elusive (Alleman, 2002;Koskela Gregory, 2002). One searches in vain for a rigorous basis for ITIL, TOGAF, COBIT, or CMMI. ...
Working Paper
Full-text available
Author’s note Direct efforts on this working draft are discontinued and it will not be submitted for publication in this form. It was a working vehicle, helpful for a time in assembling citations and thinking. For published work, see the report “Renewing the IT Curriculum: Responding to Agile, DevOps, and Digital Transformation” available at http://www.dynamicit.education, or for download on ResearchGate (https://www.researchgate.net/publication/309980701_Renewing_the_IT_Curriculum_Responding_to_Agile_DevOps_and_Digital_Transformation). Abstract The use and importance of information technology is accelerating throughout the economy, a movement known as “digital transformation.” New delivery techniques are emerging, oriented around a core of Agile software development. Agile as a movement has extended its reach into product management, operations, IT infrastructure, and many other aspects of management information systems,notably in the recent movement termed “DevOps.”Established practices such as waterfall software development, project management, and the use of IT process frameworks are being questioned. Workforce requirements are shifting, and there is a need for an updated educational response more consistent with digital trends. Existing curricula are analyzed for fit with the new trends. A new learning progression based on a “scaling” narrative is proposed as a basis for reference curricula.
... Project management is part of a management discipline [42]. Project management is meant to control software project according to project plan. ...
Article
We develop a mathematical model of backlash inverse and give a parametrization of the error caused by its estimate. We then design an adaptive backlash inverse controller for unknown plants with backlash and show the global boundedness of the dosed-loop signals. Simulations show major improvements of system performance.
Chapter
The ICSE 9 paper, “Software Processes are Software Too,” suggests that software processes are themselves a form of software and that there are considerable benefits that will derive from basing a discipline of software process development on the more traditional discipline of application software development. This paper attempts to clarify some misconceptions about this original ICSE 9 suggestion and summarizes some research carried out over the past ten years that seems to confirm the original suggestion. The paper then goes on to map out some future research directions that seem indicated. The paper closes with some ruminations about the significance of the controversy that has continued to surround this work.
Article
Few will still doubt that our modern technological culture has reached a turning point, and that it must change drastically if we are to manage our environmental problems. It may not yet be as widely appreciated that science, hitherto the mainspring of that technological progress, must also change. From now on its central task must be concerned with the patholo-gies of our industrial System; and this imposes new problems and requires new methods. These are the subject our of study.
Book
Perspectives.- A Dialogue on Ill-Defined Control.- Hijmans and Their Relation to Ill-Defined Systems.- Some Themes and Primitives in Ill-Defined Systems.- The Use of Optimal Control in Economics.- Biological Views of Adaptation - Some Historical Accounts.- Control Theory Mb Non-Linear Analysis.- Adaptive Behavior in Manual Control and the Optimal Control Model.- Regulation, Feedback and Internal Models.- The Dynamics of Adaptation in Living Systems.- Artificial Intelligence.- Adaptive Control: From Feedback to Debugging.- The Role of the Critic in Learning Systems.- Examples and Learning Systems.- Conceptual Models of Ill-Defined Systems.- Motor Skills.- Creativity in Skilled Performance.- The Concepts of 'Adaptation' and 'Attunement' in Skill Learning.- Visuomotor Coordination: From Neural Nets to Schema Theory.- Language Acquisition and Adaptation.- Richly Specified Input to Language Learning.- The Sensible Brain: Adaptation as a Positive and as a Negative Factor in the Reorganization of Neuropsychological Systems After Brain Damage.- Development and Evolution.- Piaget and Education.- Implications and Applications of Piaget's Sensorimotor Concepts.- Failure is Not the Spur.- Genetic Algorithms and Adaptation.- Contributors.- Author Index.
Article
The ″iterative enhancement″ technique is recommended as a practical means of using a top-down, stepwise refinement approach to software development. This technique begins with a simple initial implementation of a properly chosen (skeletal) subproject which is followed by the gradual enhancement of successive implementations in order to build the full implementation. The development and quantitative analysis of a production compiler for the language SIMPL-T is used to demonstrate that the application of iterative enhancement to software development is practical and efficient, encourages the generation of an easily modifiable product, and facilitates reliability.