There is much confusion in the domain of project management and especially software projects between complexity, complex, and complicated. Wikipedia definitions almost always fall short.
The book on the left is the latest addition to this topic in the domain of agile software development. The book is based on an Adaptive Complex Project Framework. The notion, a naive notion, that complexity can be reduced and complex systems should be avoided, is just that notional. In practice complex systems can't be avoided in any business or technical domain where mission critical systems exist. That is non-trivial systems are complex.
These systems include System of Systems, Enterprise Systems, Federated Systems, and system in which interaction with other systems is needed to accomplish the mission or business goal.
The book emerged from a 2010 IBM report of 1,541 executives in 60 countries about the preparedness for complex systems work. Capitalizing on Complexity. From the report there are ten Critical Success Factors, in priority order:
- Executive support - if those at the top aren't willing to support your project, it's going to be difficult to get help when things start going bad and they must go bad, because projects break new ground and this creates push back from those uninterested in breaking new ground.
- User involvement - projects are about users getting their needs met through new capabilities, delivered through technical and operational requirements.
- Clear business objectives - if we don't know what Done looks like in units of measure meaningful to the decision makers, we'll never recognize Done before we run out of time and money.
- Emotional maturity - project work is hard work. If you're easily offended by blunt questions about where you'e going, how you're going to get there, assures that when you arrive the product or service will actually work and wat evidence there is to show you spend the money wisely - you're not ready for project work. Project work is about projects. People deliver projects, but it's about the mission or business goal. Maturity in all things is required for success.
- Optimizing scope - full functionality can never be foreseen. But a set of needed capabilities must be foreseen if the project is not to turn into a death march - exploring and searching for what Done looks like. Only in a research project do capabilities emerge. If you're spending your customers money, have some definitive notion of what capabilities will result from this spend. What Measures of Effectiveness and Measures of Performance will be used to assure progress is being made toward the goal of delivering those capabilities.
- Agile process - no one has visibility to what will emerge in the future. Be prepared - the Boy Scout Motto - for new information and surprises. Ask and answer how long are you willing to wait before to discover you are late, over budget, and the gadget you're building doesn't work? The answer is ½ the time needed to take corrective action. In other words, determine progress to plan iteratively every few weeks so you have sufficient time to fix what you broke. This is a pur closed loop control system problem. The sampling rate to remain in control is the Nyquist rate, and it is ½ to rate of change of the control variable.
- Project management expertise - managing projects is all about having a plan, a sequence of work activities the deliver incremental, increasing maturity capability for the planned cost, to produce the planned value. All measures of cost and value at monetary.
- Skilled resources - work gets done by skilled, experienced people. If they've not seen the problem before or know someone who has, then it's going to be a rough ride.
- Execution - it's all about execution. Execution at a sustainable pace, with tangible outcomes that be assessed for their increasing maturity in units meaningful to the decision makers. The notion that working software has to be delivered every few days is totally domain dependent. The notion that requirements go stale is equally domain dependent. Don't listen to anyone with any idad that doesn't define the domain of where that idea is known to work. Such a person is just blowing smoke.
- Tools and Infrastructure - tools are critical. Any complex project is too complex for one person to manage the data, processes, people, and progress. When you hear complexity is bad, reduce complexity, ask if they have ever actually managed a complex project? No, be quiet.
