Conquering Complexity: Integrating USAF IT Programs & Process Presented by Stephen Lahanas

Introduction “ Almost all grave software problems can be traced to conceptual mistakes made before programming started.” Scientific American - 2006 Complexity is the number 1 reason why IT projects fail The best time to resolve complexity is at project onset The only thing worse than a complex project is many complex projects COTS implementations and integrations are subject to the same risks as custom development All IT projects share similar lifecycle processes Individual Program Plans (e.g., ECSS, DEAMS, HR…)

“ Almost all grave software problems can be traced to conceptual mistakes made before programming started.” Scientific American - 2006

Complexity is the number 1 reason why IT projects fail

The best time to resolve complexity is at project onset

The only thing worse than a complex project is many complex projects

COTS implementations and integrations are subject to the same risks as custom development

All IT projects share similar lifecycle processes

The USAF Challenge Overall Air Force Installations and Logistics Portfolio (716) Multi-dimensional problem AF/IL is only part of the AF IT Complexity Puzzle Complexity takes many forms: Organizational diversity – dozens of PMOS, 100’s of service providers Process variation – decades of cultural optimization Systems & infrastructure environments – 1000’s to manage; worldwide Technology evolution – The capability gap

Complexity takes many forms:

Organizational diversity – dozens of PMOS, 100’s of service providers

Process variation – decades of cultural optimization

Systems & infrastructure environments – 1000’s to manage; worldwide

Technology evolution – The capability gap

The Complexity Equation Initiative Risk Complexity = Problem dimensions x issue variables This could be measured as a ratio or tracked as data If tracked as data how would it be represented ? The number of data items related to the complexity equation for USAF ERP initiatives would likely number into the 100’s of thousands There must be a common mechanism between service providers to share this information There must be a shared Flexible set of processes & lexicon for managing both ERP and legacy issues Impacting 500 + AF Systems

Complexity = Problem dimensions x issue variables

This could be measured as a ratio or tracked as data

If tracked as data how would it be represented ?

The number of data items related to the complexity equation for USAF ERP initiatives would likely number into the 100’s of thousands

There must be a common mechanism between service providers to share this information

There must be a shared Flexible set of processes & lexicon for managing both ERP and legacy issues

Finding the Lingua Franca A shared framework Complexity requires flexibility There are several process elements shared by all projects, however the processes are not, cannot be perceived or managed exactly the same way There are at least 3 typical organization roles within any DoD IT project: Functional Customer – End User Program management office Developer These roles are usually represented different offices, but all tend to follow the general guidelines of DoD 5000

Complexity requires flexibility

There are several process elements shared by all projects, however the processes are not, cannot be perceived or managed exactly the same way

There are at least 3 typical organization roles within any DoD IT project:

Functional Customer – End User

Program management office

Developer

These roles are usually represented different offices, but all tend to follow the general guidelines of DoD 5000

Requirements Management The Next Generation Requirements bind all participants Requirements provide a framework for managing project related data Requirements management is already integrated into DoD 5000 guidance Requirements link all elements of the typical IT lifecycle Unfortunately… Requirements management typically is not automated and when it is only in an ad hoc manner Requirements typically are not integrated with architecture Requirements management is usually relegated as specialized task to a few analysts as opposed to being open to all key stakeholders

Requirements bind all participants

Requirements provide a framework for managing project related data

Requirements management is already integrated into DoD 5000 guidance

Requirements link all elements of the typical IT lifecycle

Unfortunately…

Requirements management typically is not automated and when it is only in an ad hoc manner

Requirements typically are not integrated with architecture

Requirements management is usually relegated as specialized task to a few analysts as opposed to being open to all key stakeholders

Requirements Management Done Right The Do’s & Don’ts Do – begin all projects with requirements coordinated up front rather than as an afterthought Do – use requirements to bring together users, service providers and developers Do map their unique perspectives to a shared taxonomy – allowing for multiple processes but one shared set / repository of integrated requirements [functional, technical & user] Do use requirements as the basis for JAD forums and user group management Do associate requirements with all project strategies milestones, risks and issues Don’t develop requirements using unstructured data formats (i.e. MS Word) or using tools with limited access (expensive, client server tools) Don’t create Conops and COI vocabularies without using those as a taxonomic basis for follow on requirements and architecture Don’t assume everyone has the same understanding – validate & often !

The Do’s & Don’ts

Do – begin all projects with requirements coordinated up front rather than as an afterthought

Do – use requirements to bring together users, service providers and developers

Do map their unique perspectives to a shared taxonomy – allowing for multiple processes but one shared set / repository of integrated requirements [functional, technical & user]

Do use requirements as the basis for JAD forums and user group management

Do associate requirements with all project strategies milestones, risks and issues

Don’t develop requirements using unstructured data formats (i.e. MS Word) or using tools with limited access (expensive, client server tools)

Don’t create Conops and COI vocabularies without using those as a taxonomic basis for follow on requirements and architecture

Don’t assume everyone has the same understanding – validate & often !

ECSS Requirements Legacy or ERP or Both ? The Big Picture There are thousands of legacy requirements ‘stacked’ in a holding pattern while funding is allocated to ECSS (2 years and counting) it is also likely that there is no central repository of for all of these requirements It is not clear whether all the legacy capabilities can or should be replaced It is not clear when those that clearly are replaceable by ERP modules will be replaced (how many more years will the USAF have to wait ?) The current approach is often referred to as a ‘big bang’ strategy, an all or nothing gambit, but does it have to be ? If the USAF wished to assess each requirement in each system against all of the ERP ‘to be’ requirements, how would they accomplish this, how many thousands of requirements would there be ? How will the functional customer, program office and integrator be able to sing from the same sheet of music – what mechanism is in place besides powerpoints to unify the reporting and analysis between these groups so that all know the same information – track the same requirements ?

The Big Picture

There are thousands of legacy requirements ‘stacked’ in a holding pattern while funding is allocated to ECSS (2 years and counting) it is also likely that there is no central repository of for all of these requirements

It is not clear whether all the legacy capabilities can or should be replaced

It is not clear when those that clearly are replaceable by ERP modules will be replaced (how many more years will the USAF have to wait ?)

The current approach is often referred to as a ‘big bang’ strategy, an all or nothing gambit, but does it have to be ?

If the USAF wished to assess each requirement in each system against all of the ERP ‘to be’ requirements, how would they accomplish this, how many thousands of requirements would there be ?

How will the functional customer, program office and integrator be able to sing from the same sheet of music – what mechanism is in place besides powerpoints to unify the reporting and analysis between these groups so that all know the same information – track the same requirements ?

Organizational vs. Functional Multiple Views of the same data The requirements are the same, The perspectives are relative

A Shared Repository – Enterprise Scale Multi-Party RM Process This view illustrates DoD 5000 as the shared basis for several core groups to correlate requirements in context with the high level phase release approach. The requirements cut across all groups and support / link all deliverables. All of this foundation can be captured within the repository as data (and can be used to help create key deliverables.

Requirements & NCES Core Integration as Services Lifecycle Automation Tools as Services The need for Enterprise Lifecycle integration is common across the DoD Providing tools to allow the DoD share information across 100’s or 1000’s of offices will revolutionize IT management Requirements are the first stage towards building that common picture Products built on SOA A Requirements Management tool built using SOA can plug-in to the NCES as a product line offering RM data can be exposed through discovery services or within RM service

Lifecycle Automation Tools as Services

The need for Enterprise Lifecycle integration is common across the DoD

Providing tools to allow the DoD share information across 100’s or 1000’s of offices will revolutionize IT management

Requirements are the first stage towards building that common picture

Products built on SOA

A Requirements Management tool built using SOA can plug-in to the NCES as a product line offering

RM data can be exposed through discovery services or within RM service