1. Is Agile Project Management
Systems Engineering?
Systems Engineering ensures the
whole product works together with its
external systems to meet the needs of
the customer

2. Agile Project Management can be directly
derived from Systems Engineering concepts
 With a SE approach, agile
Robust Design and Development
PM now has a solid Process and Methodology
foundation in theory and in
practice.
 ―Anecdotes,‖ can be Accelerated System Integration and Testing
replaced by academic
foundation Agile Systems
Agile Product
Development
Engineering and
Strategies and
Architecting
Approaches
Agile Development Drivers
Technology – Market - Regulations

3. “Whole” and “external” are core components
of systems engineering. They also connect us to
agile project management.
 Whole: meaning all  External: meaning
aspects of product all the participants
delivery  Internal customers
 Technical
 External customers
 Business
 Partners
 Operations
 Deployment  VARs
 Maintenance  ISVs
 Withdrawal  Funders

4. The idea of “agile” systems and management
goes back long before the current paradigm
change in Agile Project Management
 Evolution is a technique for producing the
appearance of stability. A complex system will be
most successful if it is implemented in small steps
and if each step has a clear measure of successful
achievement as well as a ―retreat‖ possibility to a
previous successful step upon failure. You have the
opportunity of receiving some feedback from the real
world before throwing in all resources intended for a
system, and you can correct possible design
errors... Tom Gilb, 1976

5. Traditional approaches to management start
with “plans.” These plans are characterized by
both their behaviors and their artifacts
 Work is planned in stages
 Single pass or sequential development of
detail
 Doucment driven communication processes
 Open loop (sequential) feedback

6. We’ve known for a long time of the “dangers”
associated with sequential, open loop systems,
even though we easily fall into the trap is using
them in our current work processes
 …there are dangers, too, particularly in the conduct
of these [waterfall] stages in sequence, and not in
iteration, i.e., that development is done in an open
loop, rather than a closed loop with user feedback
between iterations. The danger in the sequence
[waterfall approach] is that the project moves from
being grand to being grandiose, and exceeds our
human intellectual capabilities for management and
control. — Mills, 1976.

7. Systems Engineering impacts on
the sequential processes of the
past
Systems engineering takes a different
approach to work processes. One based on
the integrated ―whole,‖ defining both the
product and the process in a continuously
evolving improvement paradigm

8. Systems Engineering touches a variety of topics
in a software development project. Not
controlling these processes, but integrating
there products and processes
 Systems engineering
enables subsystems to
Soft Systems
interact through a protocol Engineering Human
Systems
Software
Engineering
Management
of interfaces
Enterprise Verification
 The rhythm of the project Management
Project Systems
And
Validation
is built around the flow of Management Engineering
Hardware
value through systems Engineering
engineering

9. Why do we need project management at all in
an agile project environment?
 Customers demand insight into the use of their
funding from a ―risk management‖ point of view
 Measures of progress go beyond the linear
production of code from a customer list of ―stories‖
 Coordination extends beyond the boundaries of a
small group of developers into groups of strangers.

10. Where does the solution to these needs start?
Create normative rules of compliance or
heuristics to address needs?
 Using Rechtin' s four classifications
 Normative
 Rational
 Participative
 Heuristic
 The normative approach results in ―guidebooks‖ of
how to manage a projects
 Rational approaches (Systems Engineering) provide
the basis of Participative and Heuristics methods

11. What is Project Management?
What is Agile Project Management?
Why are they different from each other?
What does this mean to the profession?
 The normative answer is not very satisfying for agile participants
 Fernando Flores, PhD Thesis Communication and Management
in the Office of the Future, University of California Berkeley,
1982, says it better in our agile vocabulary:
Management is that process of openness, listening, and eliciting
commitments, which includes a concern for the articulation and
activation of the network of commitments, primarily produced
through promises and requests, allowing for the autonomy of the
productive units.
 Apply the Flores definition to projects and we’ve got an agile view
of Project Management through the eyes of a Systems Engineer
 Remember the ―whole‖ and ―external‖ attributes of systems

12. The confusion between traditional and agile
starts with the false assumption that
“traditional” project management is not
concerned about value production
 The premise that ―traditional‖ project management is
not focused on the same things ―agile‖ project
management is misguided at best and poorly
informed at worse
 ―Traditional‖ project managements places these
concerns in the ―business management‖ domain, not
the project management domain
 ―Traditional‖ project management is focused

13. Adding business management to project
management “may” be the basis of agile project
management, but some more thought is needed
to understand the consequences
 Systems engineering (systems management)
has similar concerns
 Product and process performed in parallel
 Value focused decision making – trades
 Systems Engineering has a firm foundation of
process and theory
 Project management is but one part of Systems
Engineering

14. Why do we care about this definition?
How does this definition influence how we talk
about project management?
 If Project Management is just about the processes
then we’re missing the solution to most of the
problems
 Flore’s ―management‖ definition
 It’s the People!
 The PMI definition is necessary, but not sufficient for
success
 A human centered process are missing
 Defining ―what does done look like‖ is the starting
point

15. Long before the current paradigm discovery
Iterative Development was the basis of good
systems engineering practices
 The basic approach [Randell‘s and Zurcher‘s Iterative
Development] recognizes the futility of separating design,
evaluation, and documentation processes in software-system
design. The design process is structured by an expanding model
seeded by a formal definition of the system, which provides a
first, executable, functional model. It is tested and further
expanded through a sequence of models, that develop an
increasing amount of function and an increasing amount of detail
as to how that function is to be executed. Ultimately, the model
becomes the system.
— Lehmann, 1969

16. Common themes that Agile Project
Management professes are claimed to not be
present in other approaches
 Significantly less documentation is needed to
define the needs of the project
 Small development cycles
 Emphasis on team work and collaboration
 Adaptive development processes
 What is recognized is – these are the
principles of Systems Engineering as well

17. What is a System and what is the discipline of
Systems Engineering?
How is this important to Agile Project
Management?
 System – is an interacting combination of
elements, viewed in relation to function
 Machine elements (algorithms, processes, rules)
 Environmental elements (external influences)
 Human elements (interactive behaviors)
 Emergent behaviors (alterations to behavior)
 Systems Engineering – is the art and science
of creating complex systems

18. Complex systems are the target space of
Systems Engineering. Integrating the product
and the process is the basis of complex adaptive
systems. Both interact to form a “system”
 The systems approach is fundamentally
different from ―traditional‖ project
management
 But, systems engineering still uses core
project management processes
 It combines product and process in a single
discipline.

19. What Are The Elements Of
Project Management?
There are several descriptions of ―project
management.‖ The current agile approaches
do not include the normative components, this
is likely a gap that needs to be filled before
they can be applied outside agile software
development

20. If project management as a profession is well
developed, why don’t we recognize the
elements of project management in agile project
management?
 Project Management Institute elements
 Software Engineering Institute CMMI IPPD
Project Management
 Prince2

21. What are the elements of a
systems management process?
No matter what the software
development methodology, a set of
systems management processes can
be found in some form

22. Systems management processes are the basis of
agile project management
 Management – code development needs
 Organization – staffing and business
processes
 Engineering – building the system requires
more than just stories and coding processes

23. Management processes involved in the project
management activities. These activities involve
both people and processes. Scaling these
process outside the small group is an issue
 Subcontract management
 Inter-Group Coordination
 Risk management
 Tracking and Oversight
 Quality management
 Configuration Management
 Planning
 Data management

24. There are organizational processes involved in
project management as well
 Competency development
 Technology management
 Process management and improvement
 Environment and Tool support

25. Systems engineering processes can now be
connected to the project management processes
 System concept definition  Making this connection
 Requirements and breaks the normative
functional analysis paradigm
 System design  Replacing it with a
participative and heuristic
 Integrated engineering
paradigm of agile project
analysis
management
 System integration
 System verification
 System validation

26. A systems engineering view
of requirements
Design ideas can not be judged or
validated except with respect to the
functional, quality, and cost
requirements they must satisfy
– Tom Gilb

27. Requirements are part of the process not matter
the project management method is used – agile
or not
 How can any software process be successful
if it does not attack the requirements?
 Agile methods use testing to provide
validation
 Requirements are identified through
prototyping
 Agile processes do not explicitly address of
verification

28. What is requirements management all about?
The process of managing change to the
requirements for a system
 The principal concerns of requirements
management
 Managing changes to agreed requirements
 Managing the relationships between requirements
 Managing the dependencies between requirements
 Managing requirements without traceability?
 A requirement is traceable is the requestor is known,
the reason the requirement exists is known, how the
requirement relates to other requirements and how it
related to the architecture, implementation and user
documentation.

29. Stable requirements and volatile requirements –
they’re the same and they’re different
 It is common in all projects the requirements
chances occur while they are being elicited
 Stable requirements concern the ―essence‖ of
the system and its application domain
 Volatile requirements are specific to the
instance of the system in a particular
environment or product configuration.

30. Factors influencing requirements changes can
be addressed by project management processes
 Requirements errors, conflicts, omissions,
inconsistencies
 Evolving customer, market, and user-
knowledge needs
 Technical, schedule or cost changes
 Changing market or customer priorities
 Organizational changes

31. Volatile requirements is too broad a term to be
useful in practice. Here are four simple classes
of requirements volatility found in systems
engineering
 Mutable – environmental changes
 Emergent – as the system develops
 Consequential – new assumptions of use
 Compatibility – equipment or process

32. Traceability from requirements to deliverable
elements of the project forms the basis of
“testing” compliance with customer needs
 Information used to assess the impact of
requirements changes
 Types of traceability
 Backward from – links requirements to their source
 Forward from – links requirements to design
 Backward to – links design and implementation to
requirements
 Forward To – links documents to relevant requirements

33. Verification and Validation are part of the
project management domain as well as
development
 Verification – ―are we building the product
right?‖
 Validation – ―are we building the right
product?
 Test – validation – is different from inspection
– verification.

34. The tyranny of requirements is independent of
the project management methodology
 ―If someone is trying to contract for a system, and they can
properly identify all the necessary ‗requirements‘, then it makes
sense to do so. The preference then usually becomes: ―meet the
requirements, and pick the lowest cost.‖ But the reality is, in
every complex system I've seen, ―most ‗requirements‘ aren't.‖
Given the right combination, nearly any ‗requirement‘ will be
relaxed to obtain some other gain. The real preferences are
hidden behind the ‗requirements‘ in some operational analysis
space. … As soon as someone lists a set of ‗requirements‘
without indicating what makes one system better than another,
they've lost the information for comparison.‖
– Eric Honour, President INCOSE

35. The inevitable pain of software development
comes from the efforts to manage requirements
in the presence of change
 Every major aspect of software development includes
at least one step that is so painful that programmers
habitually avoid it. The biggest problem is
remembering all the requirements. You get more
requirements while working on initial requirements.
you forget to write them down in the excitement of
coding, and feel guilt if you spend too much time on
requirements, instead of coding. Changing
requirements cause the most pain of all.
– Dan Berry, University of Waterloo, Waterloo Ontario

36. Why do we need to augment agile software
development with Project Management?
Where’s the value to agile software
development?
 Multiple phases of product development exist
in any sufficiently complex environment
 Exploration – research, concept synthesis,
product and market analysis
 Development – technical management,
development lifecycle processes
 Operations – field operations, minor updates,
anomaly resolutions

37. Systems engineering processes address the gaps
between agile development methods and their
business management
 Systems engineering considers the Full lifecycle of
product development
 Exploration
 Customer needs
 Technologies
 Concept of operations
 Development
 Technical management
 Operations
 Field operations
 Maintenance, update and support

38. How can we recognize the right process when
we see it?
 Are there work products that go unused?
 Documents
 Analyses that don’t turn into features
 Is product quality at the target level?
 Rework
 Field problems
 Is project performance at the target level?
 Cost and schedule performance
 Value connected to investment

39. Project management is really a technical
business management discipline. Agile software
development is product development. They are
not competitors
 What is project management?
 PMI processes: Initiating, Planning, Executing, Controlling,
Closing
 CMMI IPPD PM processes: Planning, Monitoring and
Control, Supplier Management, Integrated Product
Management, Risk Management, Integrated Teaming
 The agile paradigm must address each of these
traditional process areas
 If it doesn’t then is agile project management, project
management – or something else?

40. Primary role of Agile “project management” is
focused on the same things as “traditional” PM
– the delivery of value to the customer.
 Verify that the ―right‖ plan is being followed
 Traditional Project Management takes action in the
presence of deviations
 Process areas do not question of the plan is the right plan
 Agile Project Management focuses on the flow of
ideas rather than task completion
 Know the Significant Accomplishments
 What does ―done‖ look like?
 Are we building the right thing?

41. Technical aspects of Systems Engineering and
Agile Project Management
 Architecture – existing and new capabilities
 Analysis – capacity usage, response time,
allowed usage
 Operational concepts – new requirements
 Balancing disciplines – overview of all the
aspects of the system

42. The core of any agile project management
process – experimentation
 Experimentation matters because it is
through learning equally what works and
what doesn‘t that people develop great new
products, services and entire businesses. But
in spite of lip service that is aid to ―testing‖
and ―learning from failure,‖ today‘s
organizations, processes, and management
of innovation often impede experimentation.‖

43. Three stages of project control systems.
Assessing the stage is critical to assessing the
project’s success
Stage 1: Stage 2: Stage 3:
Chaos Prescriptive Control Adaptive Control
 Minimum  Conformance to  Conformance to
controls plan acceptable results
 ―Just do it‖  ―Plan the work, work  ―Embrace
 Undefined the plan‖ change‖
lifecycle  Task based  Iterative,
(horizontal planning) incremental and
feature Driven

44. Tom Glib’s Evolutionary Systems Engineering
Approach is a nice bridge between Agile Project
Management and Systems Engineering
 Decompose the problem by  Design to cost
performance results and  Design to performance
stakeholders
 Do the high risk steps first  Invest in open ended
and learn how the unknowns architectures early
really perform  Motivate the team through
 Focus on improving the most results rewards
valuable performance  Prioritize changes by value
objectives first not by their place in the
 Base early evolution on queue
existing frameworks and
stakeholders  Learn fast, change fast,
adapt to reality fast

45. Bibliography
 B. Randell and F.W. Zurcher, ―Iterative Multi-Level Modeling: A Methodology for
Computer System Design,‖ Proceedings of IFIP, IEEE CS Press, 1968, pp. 867-871.
 C. Larman and V. R. Basili, ―Iterative and Incremental Development: A Brief History,‖
IEEE Computer, June 2003, pp. 47-56.