System Archetypes

Here are some well-known examples of system archetypes in software-intensive enterprises:

Attempting to add staff to an already late software project makes it later; this is known as the “Brooks’ Law.”
"Cool new features" proposed in an ad hoc way by senior executives or directly implemented by developers as their own cool ideas makes a mockery of the development schedule.
Attempting to remove errors from a legacy software system causes the number of latent errors to increase.
Heroics to resolve a crisis in software project undermines the ability to develop long-term and enduring solutions to the crisis.
Excessive emphasis on the success of one product development project cripples other product development projects or comes at the expense of on-going software process improvement efforts.
After the initial enthusiasm and commitment to software process quality generated by winning a software quality certificate or certain process maturity level grade, software process compliance erodes resulting into a downgrading in the software process maturity level.
Many software projects spend 95% resources on completing the first 95% of the project, but always need additional 95% resources to complete the remaining “5%” of the project! … and that last 5% of the work never seems to end.

Solutions developed with systems thinking and system dynamics to some of the system archetypes listed above are described below:

Attempting to add staff to an already late software project makes it later.

Resist the temptation for doing so; negotiate increased schedule or reduced scope of work instead of reduced staff at a late stage in a project.
A solution which is very consistent with agile development principles is to postpone adding new staff until the next iteration (i.e., next sprint in the SCRUM framework).
If you must add staff, use system dynamics modeling and simulation to quantitatively understand how late in the project you can add new staff which will yield the desired benefits, and not cause more project delays. Also improve coordination among project members and institute close mentoring program for new staff immediately.

"Cool new features" proposed in an ad hoc way by senior executives or directly implemented by developers as their own cool ideas makes a mockery of the development schedule.

For agile development process, resist adding any cool new features in the middle of an iteration (Scrum sprint). Such proposed features need to wait for the next sprint (usually at most 30 days away), or some other yet-to-be implemented features in the current sprint must be pushed out to the next sprint, or the current sprint is cancelled and new sprint planning is immediately initiated. All such "cool new feature" request must be highly visible for everyone to see, which creates the necessary system pushback to new proposed features in the midst of a sprint.
For traditional development processes, try to quantify the impact of "cool new features" in terms delays in schedule, increased cost, reduced quality and increased risks. System dynamics models can be built and simulated to quantify and visualize these adverse effects. Then negotiate the revised schedule and/or cost, etc. Use change management system to follow the process of dealing with such changes.

Attempting to remove errors from a legacy software system causes the number of latent errors to increase.

Spend time and resources to improve software maintenance documents.
Train software maintenance staff on complex portions of the system to maintain legacy software systems.
Reverse engineer portions of the system that are most error prone and difficult to maintain.
Follow regular and systematic design re-factoring discipline in each iteration or release cycle to improve the design so software can evolve and change more robustly without introducing new errors.
Develop system dynamics models to simulate design re-factoring effects in order to quantify their cost and benefits and then take an appropriate decision.

Excessive emphasis on the success of one product development project cripples other product development projects or comes at the expense of on-going software process improvement efforts

Either properly provide critical mass resources for a project, or show mercy by closing the project at an early stage instead of keeping the under-resourced project “running” forever.
Develop and nurture cross-trained development and QA staff on a diverse set of technologies, domains and environments so the staff can be flexibly deployed across multiple projects reducing the likelihood of only the star performers are available to work on high-visibility projects, and other projects starve or languish.
Develop system dynamics models to simulate and quantify how the ripple effects of delays or resource changes in one project cascade through other projects.

After the initial enthusiasm and commitment to software process quality resulting from winning a software quality certificate or certain process maturity level grade, software process compliance erodes.

Identify key quality indicators or measures for each project and measure them periodically in order to take proactive and corrective actions; do not wait for ISO 9000 or CMMI audits to pay attention to these measures and shape up the organization to an increased quality level.
Create and nurture the systems for continuous quality improvements with proper measurements, rewards and incentives irrespective of external quality certificates or grades. If necessary, show these effects (cost and benefits) by building and simulating system dynamics models.

Services: Training | Workshops | Consulting | Management | IP Development