Delivering Change

The first thing to address is how technology  is delivered.  The history of IT "failure" is significant.  Although there have  been improvements, the core reasons are consistent.  They primarily fall into  four  categories - basic planning, communication, decision  making, and technology.  The larger the project the more susceptible to the  issues.  This  is why agile and continuous improvement are so attractive.  

The slide is telling

This slide (although a few years  old) showed that, even with the  advent of certified project management, experts in architecture, and agile methods, project delivery  has not gotten significantly  better.  It further shows  that  the  larger the  project the less likely for success.  

Although there may  be great improvements  on the horizon (AI design,  AI code, AI  testing), faster delivery  does not always translate into  better products.  In the  real  world where not everything  is a  green field  and there is potential for  impact on  current  operations.   With current stakeholders (some with critical  needs) "fail fast" does not  work.  It  could cost lives.   

The  following word cloud  was  derived from analyzing why  projects  failed.

The  same reasons have  existed for years.  It is planning, communication, decision making, and technology.  We have all seen these excuses for  project failure (and even used some).  

These problems exist even in an agile  world.  It is most evident when agile  is not based on a robust technical  foundation.  In order to meet sprints, teams are often encouraged to  be creative (heroic programming).  This leads to either  refactoring in the future, or a solution that is  hard  to  support.  

Agile weaknesses get exposed in a solutioning environment.  Where every  problem is thought to be unique.  Where every  project seems to have specialized requirements.  Although agile is designed to facilitate  change, solutioning  can make  those  changes  localized and harder to support.  

Agile  thrives in an API/services/Product environments where common consumption patterns serve as the  foundation  (The Right Strategy).  Every project, every  sprint is delivery of capabilities within products (EA Diagram).  Some capabilities may take longer to develop than a sprint, but they  can often be developed as a capability within a product independently (new features).  All changes follow a  continuous improvement trajectory.  

The  product  delivery  philosophy  empowers  SDLC business partnerships.  

By standardizing change (capabilities delivered within an EA domain product), delivery can be optimized and unleashed.