Principles, Processes, and Practices to Increase Probability of Project Success

May 18, 2015

Essential Reading List for Managing Other People's Money

Education is not the learning of facts, but the training of the mind to think - Albert Einstein

So if we're going to learn how to think about managing the spending of other peoples money in the presence of uncertainty, we need some basis of education.

Uncertainty is a fundamental and unavoidable feature of daily life. Personal life and the life of projects. To deal with this uncertainty intelligently we represent and reason about these uncertainties. There are formal ways of reasoning (logical systems for reasoning found in the Formal Logic and Artificial Intelligence domain) and informal ways of reasons (based on probability and statistics of cost, schedule, and technical performance in the Systems Engineering domain).

If Twitter, LinkedIn, and other forum conversations have taught me anything, it's that many participants base their discussion on personal experience and opinion. Experience informs opinion. That experience may be based on gut feel learned from the school of hard knocks. But there are other ways to learn as well. Ways to guide your experience and inform your option. Ways based on education and frameworks for thinking about solutions to complex problems.

Samuel Johnson has served me well with his quote...

There are two ways to knowledge, We know a subject ourselves, or we know where we can find information upon it.

Here's my list of essential readings that form the basis of my understanding, opinion, principles, practices, and processes as they are applied in the domains I work - Enterprise IT, defense and space and their software intensive systems.

The notion the best architectures, requirements, and designs emerge from self-organizing teams needs to be tested in a specific domain.

Many domain have reference architectures, DODAF and TOGAF are tow examples.

Architectures developed by self-organizing teams may or may not be useful over the life of the system. It depends on the skills and experience of the architects. Brian Foote has a term for self-created architectures - ball of mud. So care is needed in failing to test the self-organizaing team's ability to produce a good architecture.

Software Intensive Systems s any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole. [IEEE 42101:2011]

Such systems are by their nature complex, but estimating the attributes of such systems is a critical success factor in all modern business and technology functions.

For anyone conjecyturing estimates can't be made in complex system, this book an mandatory reading.

Estimates are hard, but can be done, and are done.

So when you hear that conjecture ask how you know that those estimates can't be made? Where's you evidence that counters the work found in this book. Not anecdotes, optioning, conjectures, but actual engineering assessment with the mathematics?

Parametric estimating makes use of Reference Classes, same as Monte Carlo Simulation

With a parametric model or a Reference Class model estimates of future outcomes can be made in every domain where we're not inventing new physics. This means there is no reason not to estimate for any software system found in any normal business environment.

This is not to say everyone can estimate. Nor should they. The excuse of we've never done this below really means you should go find someone who has.

Comments

Education is not the learning of facts, but the training of the mind to think - Albert Einstein

So if we're going to learn how to think about managing the spending of other peoples money in the presence of uncertainty, we need some basis of education.

Uncertainty is a fundamental and unavoidable feature of daily life. Personal life and the life of projects. To deal with this uncertainty intelligently we represent and reason about these uncertainties. There are formal ways of reasoning (logical systems for reasoning found in the Formal Logic and Artificial Intelligence domain) and informal ways of reasons (based on probability and statistics of cost, schedule, and technical performance in the Systems Engineering domain).

If Twitter, LinkedIn, and other forum conversations have taught me anything, it's that many participants base their discussion on personal experience and opinion. Experience informs opinion. That experience may be based on gut feel learned from the school of hard knocks. But there are other ways to learn as well. Ways to guide your experience and inform your option. Ways based on education and frameworks for thinking about solutions to complex problems.

Samuel Johnson has served me well with his quote...

There are two ways to knowledge, We know a subject ourselves, or we know where we can find information upon it.

Here's my list of essential readings that form the basis of my understanding, opinion, principles, practices, and processes as they are applied in the domains I work - Enterprise IT, defense and space and their software intensive systems.

The notion the best architectures, requirements, and designs emerge from self-organizing teams needs to be tested in a specific domain.

Many domain have reference architectures, DODAF and TOGAF are tow examples.

Architectures developed by self-organizing teams may or may not be useful over the life of the system. It depends on the skills and experience of the architects. Brian Foote has a term for self-created architectures - ball of mud. So care is needed in failing to test the self-organizaing team's ability to produce a good architecture.

Software Intensive Systems s any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole. [IEEE 42101:2011]

Such systems are by their nature complex, but estimating the attributes of such systems is a critical success factor in all modern business and technology functions.

For anyone conjecyturing estimates can't be made in complex system, this book an mandatory reading.

Estimates are hard, but can be done, and are done.

So when you hear that conjecture ask how you know that those estimates can't be made? Where's you evidence that counters the work found in this book. Not anecdotes, optioning, conjectures, but actual engineering assessment with the mathematics?

Parametric estimating makes use of Reference Classes, same as Monte Carlo Simulation

With a parametric model or a Reference Class model estimates of future outcomes can be made in every domain where we're not inventing new physics. This means there is no reason not to estimate for any software system found in any normal business environment.

This is not to say everyone can estimate. Nor should they. The excuse of we've never done this below really means you should go find someone who has.