Herding Cats

Quote of the Day

No systems can survive that doesn't serve a useful purpose - Harry Hillaker, Chief architect, General Dynamics, F-16, in Systems Architecting lecture, USC, November 1989 The classic architecting paradigm in technology projects is not the only way to create and... Read more →

Agile Stories are Actually Requirements

It's popular in the agile community to speak about User Stories and how they are Not requirements. As a System Engineer, here's some background on Systems Architecture and Requirements Engineering. Let's start with some background about Systems and their engineering.... Read more →

Deconstructing the Hertz and Accenture Debacle

A recent lawsuit by Hertz Rental Car against Accenture has turned into a rallying cry by Agilest and No Estimates advocates. Of course, No Root Cause analysis has been performed by these advocates, but it makes good click bait for... Read more →

Compendium of Works to Increase Probability of Project Success

Here's a collection of presentations, briefings, journal and conference papers, essays, book content used to increase the Probability of Project Success (PoPS) I've written and applied over my career in the software-intensive system of systems and other domains. These materials... Read more →

High Integrity, Fail Safe, Software Systems

I was an invited speaker at the University of Colorado, Boulder for an Advanced Embedded Systems Development graduate class. Here are the charts. Starting on Page 29, I was the Software Development Manager for the Tricon. Safe, Reliable, Available, High‒Integrity,... Read more →

Modeling the Future is the Basis of Project Success

There's a notion going around that ... “I don’t believe you can make a model of a possible future.” This ignores the principles of predictive analytics, and the direct management actions taken to produce outcomes from those analytical models found... Read more →

I Never Thought of It That Way

This is a new Tag for the Herding Cats blog. I've had a conversation on Twitter that started with Management installs programs to solve problems on an ad hoc basis or to move the company along instead of adjusting the... Read more →

From Strategy To Execution and Delivery

There always talk about Focus on Value. But that does that mean? What are the units of measure of Value? What does it Cost to deliver that Value? When will that Value be delivered? When is that Value Needed to... Read more →

Physical Percent Complete: Knowing When You Are Done

The goal of every program manager is to have a set of practices that connect all the programmatic planning, risk, and performance information in a single unified view needed to support the decisions that increase the probability of success of... Read more →

The Art of Systems Architecting

Performance, Cost, and Scheduling cannot be specified independently. At least one of the three must depend on the others. With few exceptions, schedule delays will be accepted grudgingly, cost overruns will not, and for good reason. The time to completion... Read more →

Separation of Concerns and Agile Development

Here's a notion that is popular in the agile community from the @agilefant tweeter feed. This notion appears when corporate governance is not part of the conversation. The role of governance is to define the decision rights of the participants... Read more →

Book(s) of the Month

December is always a busy book month in our household. We have one PhD candidate and one Masters Graduate, both the sciences (one in molecular plant biology and the other in the behavior aspects neuroscience). So books are always great... Read more →

Integrated Master Plan - Revisited

Designing, building, testing, and deploying complex systems is fraught with risk. And as always risk comes from uncertainty. And uncertainty comes in two forms - reducible (Epistemic) and irreducible (Aleatory). Much has been written about the sources of risk and... Read more →

Fallacy of the Day

Requirements, as traditionally used, are a separation tool. To separate the "thinkers" from the "doers". In software this is a HUGE mistake! This conjecture is a fallacy. The purpose of requirements elicitation, use, and implementation of the requirement that result... Read more →

Process is King Part 2

I wrote a post about Process is King a few years ago. Came across a few posts about how people trump process. That may be for small de minimus work efforts. But those same voices conjecturing people come first -... Read more →

Building the "Perfect" Schedule

I'm working on a presentation and discussion for the Joint Space Cost Council that is happening in September. Our topic is about the integration of multiple IPT (Integrated Product Teams) and how to coordinate all the work into an Integrated... Read more →

Concept of Operations

In the agile community, there is always some comment or opinion about how hard it is to define what the requirements are. How we can't possibly estimate the work since all the work is emergent. If this were the case... Read more →

4 Fallacious Reasons Why We Estimate and Why Those Are Fallacious

There's a recent post titled Four Fallacious Reasons Why We Estimate. It lists the usual suspects for why those spending the money think they don't have to estimate how much they plan to spend when they'll be done producing the... Read more →

Concept of Operations

One of the root causes of project failure is the failure to apply the first principle of the five principles of project success What does done look like in units of measure meaningful to the decision maker? Those units must... Read more →

The Economics of Decision Making on Software Projects

The classic paper “Software Engineering Economics,” Barry Boehm, IEEE Transactions on Software Engineering, Vol SE-10(1), 1984, pp. 4-21. opens with a dictionary definition of economics as a social science concerned chiefly with description and analysis of the production distribution, and... Read more →