“Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.” - Laurence J. Peter
When there is mention of the complexity of something like Earned Value, it makes me think about the context of project where EV is most appropriate:
- ERP
- Enterprise IT Integration
- Large Construction
- The obvious defense and space programs, with software intensive components
- Telecommunications systems
- Wireless infrastructure software systems
- Embedded software systems
So when it's mentioned that things like EV and probabilistic risk, cost modeling, technical risk modeling, etc. are heavy on math, I'm wondering what those developers think about the tons of code that is being developed? Is that "too heavy" to get their mind around.
Wicked Problem Domain
Most of the software systems we work - majority are defense and space but also enterprise class IT - can be classified as wicked in some way. Horst Rittel defined a wicked problem as:
- You don't understand the problem, until you've developed the solution.
- Wicked problems has no stopping rule
- Solutions to wicked problems are not right or wrong
- Every wicked problem is essentially unique and novel
- Wicked problems have no alternative solution
- Every solution to a wicked problem is a "one shot" solution
In my career experience, most the work has been on wicked problems, or something close to that.
- Radar systems
- Fault tolerance process control
- Embedded real time control (flight, turbines, nuclear emergency shutdown)
- Engineering design systems
- Programmatic controls for wicked problems
Earned Value and its value to NON-Wicked Problems?
So I'd be interested to hear a bit about non-wicked style?
Is value added to non-wicked problems by processes like EV?
If not, then maybe those challenging EV have a point. EV is not applicable to their problem.
