Agile Systems Integration

Agile Systems Integration for Open Networking Projects

Learn about Agile Systems Integration from Instructors with Real World Expertise.

This customised workshop covers all the core features of Agile Systems Integration for Open Networking projects.


This course will enable attendees to understand the holistic end-to-end scope of complex technical projects and the pressures that these projects place on existing methodologies. Graduates of this course will be able to select the right tools, processes and operating paradigms to manage or participate in these projects and contribute to high levels of success.

Agile Systems Integration (ASI) is a meta-paradigm that sits above traditional / existing methodologies. The responsibility of ASI is end-to-end management of project activities with a strong focus on customer enablement. ASI is a relatively lightweight set of concepts and guidelines aimed at managing complexity in a fuzzy project environment. The objective of ASI is to simplify how large teams deal with complexity, i.e. complexity without project complicatedness

Target Audience:

  • Project Managers
  • Program Managers
  • Delivery Managers
  • PMO Managers and PMO staff
  • Potentially any others involved in large and complex solutions acquisition or implementation (e.g. Procurement specialists, legal specialists)

Structure: This course is delivered in workshop format as a combination of lectures and other media, attendee work individually and in groups, and practical exercises.

Prerequisites: none

Duration: 3-5 days or customised to requirements

Course Outline:

What is Agile Systems Integration?


  • What is Agile Systems Integration?
  • Why do we need it?

Why is Agile Systems Integration necessary?


  • Why is Agile Systems Integration necessary for Open Networks Projects?

What problems indicate that I need ASI?


  • Multiple organisations supplying into a single project 
  • Existence of formal , complex and often stringent contracts between partners
  • Larger teams spread across multiple organisational entities and often, geographic regions
  • Need to manage significant decisions across internal and external organizational boundaries
  • Multiple systems (internal and external to the organisation)
  • Need for major organizational change management, which brings with it conflict and political power struggles in different departments, divisions, and regions
  • Impracticality of a single Product Owner: we need to deal with multiple, even a large number of, “go to” people from both a knowledge and decision-making perspective across various organisational entities
  • More stringent and complex compliance / governance processes, due to larger size and risk, which, can lead to:
  • Requirement for more detailed upfront specifications and estimates than most agile projects; and 
  • Up-front budget & timeline estimates that are typically locked into a fairly narrow range (+/- 10% is not uncommon, depending on the organisation)

Definition and Context for ASI


  • Definition of ASI
  • Context for ASI

Scope of Concern


  • Holistic and end-to-end from suppliers through to end customer’s customers
  • Technical, business, organisational, cultural 

Stakeholder Management


  • Both formal and informal mechanisms 
  • Identify all the decision-makers and influencers and how to engage them
  • Management of multiple “Product Owners”, actual or proxy, for requirements inputs and prioritisation

Dealing with “Multi-everything”


  • Managing cross-organisational escalation and conflict resolution processes
  • Extension of formal governance processes into multi-domain
  • Appropriately Rapid Decision-making: decision timeframes need to be shorter than change cycles
  • Dealing with Timezones 
  • Dealing with multiple cultures 

Managing Precision within Uncertainty


  • Advanced dependency management: between multiple points and multiple types (e.g. technical, process, governance)
  • Precise but flexible models: of requirements, solution structure (components and interfaces), resource estimates (time, cost and people). These need to be precise, contextually rigorous, easily understood and flexible

Reconciling Different Viewpoints, Processes and Paradigms


  • Agile vs Predictive vs In-house / custom
  • Process-driven vs innately agile
  • Highly iterative builds vs slower more sequential 
  • High flexibility vs high governance 
  • Speed vs Quality 

Practical Considerations


  • Removing layers, not adding them 

Looking for something else? View all courses

Start Learning

Learn from Instructors with Real World Expertise