Thanks to Ron Rosenberg for another useful post about the failure modes of projects. The Lecture can be found HERE
- The Challenge of Scale
- Middleware or Fiddleware?
- Method or Madness?
- Where are we?
- Software development is still an art
- Integration, the final frontier
- Will it really work?
- Change our greatest Challenge
1. The Challenge of Scale
The system engineering profession has a paradigm for decomposing complex problems into manageable ones. These manageable parts are still difficult at times. Flying to the moon is actually "Rocket Science" and requires rocket science level program and technical management techniques.
The first step is to determine the interdependence's at ALL levels of the problem. The standard approach is the Design (Dependency) Structure Matrix. DSM is a system engineering discipline. Lots of articles and presentations. A few clever tool for the software business is LATTIX.
The DSM paradigm is a "way of thinking," that is not well know in the standard commercial IT world. But is heavily used in Aerospace and Defense where software intensive systems are common. Dr. Tyson Browning has many papers, including his PhD thesis on this topic. These are not academic sources, but practical guidance developed at Lockheed Martin, General Electric, Boeing, BMW, and similar firms.
2. Middleware or Fiddleware?
This of course is a continuing problem in all domains. The latest is SOA. We're working a program where SOA is the glue between a large defense agencies operations and the field operations around the world. No solution comes without a price. SOA's price is that the underlying systems must be well behaved and have well defined interfaces for their "nouns and verbs."
Nothing new here, just good systems engineering is needed. With systems engineering discipline these middleware tools will be the source of project failure.
3. Method or Madness
Again a "systems engineering" approach to methods has proven best. NOT a software development method masked as system engineering or project management.
The notion that agile software development methods, Scrum, XP, and the like are replacements for good systems engineering (as practices by INCOSE qualified systems engineers) is quite frankly utter nonsense, once you get beyond 3 people in the same room with their customer.
4. Where are We?
OK, this is simple. The US Federal Government mandates Earned Value Management and an Earned Value Management Systems (EVMS) on all development programs larger than $20M. This sounds large for some domains. It's small of DoD, NASA, DOE, and the like.
You must have some means of defining and assessing physical percent complete and making corrections when variance occur.
Anyone who complains EV is too hard, too complex, just too heavy weight to be used in IT needs to get a life. Tell me an alternative method that can forecast further performance for both cost and schedule and I'll use it.
The example in the lecture about working with bridges having physical sense of progress MUST be provided in the software world with tangible, measurable evidence of physical percent complete. This is one use for agile software development IF and ONLY IF it operates inside a larger program management structure that pre-defines what "done" looks like, defines the units of measure of done in terms meaningful to the stakeholders, and guides the development process from Capabilities to Requirements to physical tangible working code elements.
5. Software Development is Still an Art
Yes, special skills and creativity are needed. They're alos needed for building bridges, flying to the moon and standing up ERP systems. But don't use the coop-out not to have discipline.
6. Integration is the Final Frontier
No one in their right mind would wait until all the parts were built for a spacecraft to start "integration and test." Why do software guys do this. This is a self inflicted wound. Stop doing this and have a continuous integration plan. Here's the full fidelity Crew Exploration Avionics Integration Laboratory (CAIL) that one of the programs we work produces hardware and software for. You'll see the logo of our customer in the 9th slide.
7. Will It Work in Practice?
In the spaceflight business there is a saying "test as you fly." This means that the spacecraft has to be nearly 100% functional before you launch, because there is no way to bring it back and do an upgrade. This is not literally true of course, because all spacecraft have software update capabilities while on orbit or at the landing site on Mars.
8. Change is Our Biggest Challenge
Managing change leads to poor outcomes. Managing in the presence of change is the alternative. This does not mean change is unchecked. It means that when change is encountered, knowing how to respond to change - manage in the presence of this change - is a formal process. Managing in the presence of change can only be successful, if there is some clarity about where the project "should" be heading.
This is usually a conversation about the needed capabilities produced by the project. The WHY and WHAT of the project. In the absence of the clarity of these capabilities, change drives the project off the tracks and into the ditch.
In The End
My personal biased opinion is many of the problems found in IT and especially enterprise IT are simply caused by the lack of understanding of how complex problems are managed in other domains. Software intensive systems are common in defense, space, petrochemicals, pulp and paper, and transportation.
We've (those of us who work in those domains) have failed to do our homework and learn the methods they use. This is one of the motivations I use to work more often with or A&D clients.
