What are the "Laws of Physics" of Software Project Management?

[jducoeur]

I'm continuing to think about ways I could contribute to the local tech-entrepreneur scene (which led to yesterday's question about basic programming principles). It occurs to me that it might be quite useful to give a talk on "The CEO and the Successful Software Project": what the CEO (especially for a startup) needs to know about managing an Agile software project, what they need to provide to the team, and what they can and can't reasonably expect from it. A large fraction of the entrepreneurs I'm meeting don't have any formal tech background, and probably mostly don't know this stuff.

(Note that this is specifically Agile from the upper-management viewpoint, so it's all about the "API" of Agile. I love pair-programming and automated testing and all that, but they're mostly irrelevant; OTOH, the rationale for the story stack, sprints, and the customer representative are vitally important.)

So I started thinking about what I might say, and this was one of the first things that came to mind:

The Uncertainty Principle: you can fully understand your feature set or your schedule, but never both. The more precisely you try to understand one, the less confidence you can have in the other.

I believe that's a straightforward lesson from the history of software development.

That quickly led to:

The First Law of Project Motion: the more precisely you attempt to understand the full scope of the project, the more inertia you add to it, and the more slowly it will move.

I'm liking this general approach -- it makes for good, pithy slides that I can then dig into and explain *why* these are generally true.

Do folks have other suggestions along these lines? I'm curious how far we can carry this metaphor before it breaks, while helping to illuminate the realities of software projects from the management level. And more generally, what would *you* like the CEO of a small software-focused company to understand?

Comments

[jducoeur]

Note to myself: much of the likely audience here are going to be focused on apps that are *not* terribly innovative -- they're really business plays, doing something in well-established niches in fairly conventional ways. They are going to have a strong incentive to outsource the application development, and that's not a *terrible* idea. Talk about the pros and cons of outsourcing:

-- Pro: if you are building something similar to what a consulting company has already built, they may have much of the expertise and tech staff ready to roll.
-- Con: you probably aren't their only customer, and their attention will, likely, be split.
-- Pro: your uncertainty is somewhat reduced if you can hire an experienced team who have done something similar to this before.
-- Con: make sure you own your IP! Don't wind up forever dependent on a third party!
-- Con: odds are good that you will wind up with no in-house expertise about the tech. If so, make sure you are *very* comfortable with the relationship here. No matter how good it is, the app will require ongoing maintenance and enhancement: make sure you know how that works.
-- Be very cautious about off-shoring. Do not underestimate the communication challenges involved in working with a team in India or Russia, both in term of language and timezones. *Many* projects fail because they are too optimistic about this, and even the successful ones often find that they don't wind up saving nearly as much as they had expected, overall.

Other points, pro and con?