15 July 2009

Getting Started

Let's take a look at two different approaches to starting a new development project:

1) I've got X dollars and Y months - what capabilities can I get?
2) I need to be able to do X - what's it going to cost me and how long will I have to wait?

In both cases, we have constraints. In the first situation, the constraint is resources. In the second, it's the need. I'm going to suggest that in reality, scenario #2 is much rarer than scenario #1. However, we all too often act like #2 is the only way to do business.

Here's the thing - we often don't really know what we need. We generally have some idea, but our understanding of the ultimate objective is going to change over time. The longer the time, the more it'll change.

That's not bad!

We should expect some change, plan for it, and seek it out. Attempting to lock down our requirements on Day 1 (when we know the least about the project) is pretty stupid... unless delivery is scheduled for Day 2. And it's entirely possible to end up with something that is simultaneously different than what we thought we needed and better than what we originally aimed for.

Let me put it bluntly: on a long project (i.e. anything over 6 months), requirements creep is good. It shouldn't be a surprise, and we shouldn't resist it. We should count on it and perhaps even insist on it.

Two additional comments: It's important for the user to be informed, educated and involved. The ultimate customer (warfighter, user, etc) needs to be continually involved in the development effort, communicating truths about the operational environment and learning about the possibilities and limitations of technology. It's also important to foster a trusting relationship between all involved. I refuse to do business with people I can't trust.


Brad Englund said...

"I've got X dollars and Y months" usually equates to "not much money and not much time". This forces a development cycle that is small, manageable, low risk, and a high confidence of getting fielded. The customer and supplier can decide things like do we add capabilities to an existing system or do we develop a new one. Developing a new system with "not much money and not much time" could imply initially fielding with only core capabilities. New capabilities can then be added under new "not much money and not much time" development cycles as new resources are available.

"I need to be able to do X" usually equates to "I need it to do everything". This forces a development cycle that is long, unmanageable, high risk, and a low confidence of getting fielded. How many recent programs failed following this pattern?

Dick Field said...

Dan --

I appreciate your comment on trust. It is all too often a rare commodity - yet it is the essential one in overcoming odds and making the whole greater than the sum of the parts. I got a reinforced sense of that in a recent visit to Pointe du Hoc, on the Normandy coast, where American Rangers scaled cliffs, under fire and having lost the element of surprise. Driving them on was a high degree of trust in one another - and the pride and audacity that resulted (aka, esprit de corps). It occurs to me that other (project) cliffs can be approached in a similar fashion.

It's too bad trust is often overlooked in the narrow perspective of typical "ethics" policy and training.

The Dan Ward said...

@Brad - great observations! It does seem that the first approach (X dollars, Y months) tends to improve the possibility of success, doesn't it?

And the other one runs the risk of asking for the moon, which is a recipe for disaster.

@Dick - it all comes down to trust, doesn't it? And ultimately, that comes down to the character of the workforce, or rather, the way leadership perceives the character of the workforce.

Brad Englund said...

Dan & Dick, your observations on trust are dead on. If you can't trust each individual on the team, you have to impose heavy process and oversight to avoid the surprises the bad apples can cause to disrupt the project.

Brad Englund said...

Just one more thing: A recent, unfortunate mishap occurred when I handed my old digital camera to my son who thought I had hold of it, and I thought he had hold of it. Shopping for a new one I quickly fell into the "I need to be able to do X" mode. It has to be small, lightweight, wide angle, long zoom, long reaching flash, large digital sensor, low noise in low light, good manual features, . . . For some strange reason, I just can't find one. Maybe those camera makers know something I don't about getting an affordable camera to market. I've now dismantled my old camera which is all in pieces on my work bench, and I'm convinced I can fix it!