In my last post “Traceability enables optimal design decisions for your program” I discussed how traceability is a great tool for the Design Authority for managing design decisions in a program across multiple work streams. In this post, I want to introduce some system dynamics around program management and how understanding the secondary effects of our decisions impact program risks and delivery efficiency. There are many versions of this system dynamics model and perhaps too complex and spaghetti-like to have an image of here. I will just discuss the key relevant ideas for Design Authority.
Complex systems are not easy for humans to understand completely. When things work well in a complex system and we can’t explain how and why, we say it is explained by “emergence” or the “invisible hand”. Complex programs have these qualities, human heroics make things happen. But, these human heroics suffer from our limited understanding of the secondary effects of our actions, sometimes causing unintended consequences and undesired outcomes that ultimately have negative impacts on the program in terms of costs overruns, missed time deadlines, lowered team morale, quality etc. In system dynamics terms, the most used models discuss the role of “undiscovered rework” as the cause that kicks off these negative dynamics.
A few of these negative dynamics below:
- Too big to manage – The bigger the project the more complex communications and coordination impacts productivity
- Burnout – When we fall behind on schedule, we sometimes kick off a death march which burns out the team, and more issues appear downstream causing more rework.
- Haste makes waste – Cracking the whip to speed up will introduce errors which then impact downstream efforts. And if you like Lean, waste is your enemy.
- Experience dilution – Hiring and staffing up to cope with the work load dilutes team experience, adds training overhead and negatively impacts productivity.
- Haste creates out-of-sequence work – All this extra rework, that is introduced through these dynamics, must be addressed, and based on the prioritization culture, these typically end up creating out of sequence work.
- Errors create more work – An obvious one, all undiscovered errors are extra work, and I am sure we did not plan for them very well.
- Hopelessness – Morale decreases as all these issues and pressures pile up.
- Product owners often change scope or requirements – People hate change, change does not care. The impacts of change ripple throughout the program.
- Poor schedule performance – slipping deadlines, causes project sponsors to lose confidence in delivery.
- Reduced product owner confidence – Lower confidence means less trust and a tightening of controls and maybe a requirement to start a death march, so it all starts over again.
What can we do to reduce the impacts of change and rework in our programs and adopt the right program behaviors that proactively mitigate these risks?
Your Design Authority (DA) is in a great position to help your program mitigate these dynamics. In addition to improving behavior through management of the rework cycle, the DA can significantly improve program performance through efforts to manage ripple and knock-on effects by
- Acknowledge that these dynamics exist and plan for them.
- Ensuring the right design standards are adhered to, and ensuring the architecture is adaptable to change. This means that sometimes the right approach is to slow down and do work right the first time.
- Evangelizing proper requirements management (user stories management). Adopting traceability practices to reduce the risk that design trade-offs will cause rework downstream.
- Ensuring robust prioritization and optimal sequencing of work. Undiscovered rework can be reduced, for example, by prioritizing rework detection and correction over starting new work.
- Ensuring testing to discover problems rather than testing to pass tests to also reduce rework cycle consequences. You can adopt test driven development and continuous integration to move the discovery of rework upstream and reduce the cost of rework (which includes all the secondary impacts of rework).
- Use integrated product teams, which improve quality and rework discovery at the expense of reduced productivity from greater communications overheads.
The DA must manage this behavioral change carefully because the implementation of mitigation activities like the ones described here initiate a “worse before better” behavior. The DA by effectively demonstrating any worse-before-better improvements and the eventual benefits of implementation, it will greatly help the program stakeholders stick with implementation. For example, allocating more resources to QA reduces “perceived progress” while actually increasing “real progress”. Such actions may be difficult to stick with unless the DA helps managers have confidence that the “better” will occur after the “worse”.
Ok, so now, after introducing the DA V-model and domains, and discussed traceability and dynamics of undiscovered rework, we are ready to dive into each of the activities the DA can perform to increase complex program delivery confidence.
Andre Michel Vargas