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?

Flat | Top-Level Comments Only

From:

dsrtao

Observer Measurement Bias: the values you use for assessing success (and awarding bonuses, raises or promotions) will be the values which are optimized.

Want to optimize number of bugs found? An infinite number can be found. Bugs closed? An infinite number can be generated and closed. Tickets resolved? They all get resolved, and customer satisfaction plumments. Low customer support call time? Hangups happen. High customer support survey scores? Cost of customer support skyrockets. Number of deals closed? Sales has promised discounts you can't support. Size of deals closed? You won't have any new small and medium customers.

From:

jducoeur

Ah -- nice one, and probably not one that would have occurred to me...

From:

laurion

Yup. This is one of the places where economics as the study of incentives and choices probably has some non-financial lessons to teach. Make sure your incentives (like looking good on a metric) match the behaviors you actually want want.

From:

dsrtao

Equality of Responsibility and Power: a person is responsible for a project to the same degree that they make decisions about it.

Reduce their decision-making ability and their responsibility for success or failure is similarly reduced. Reduce their responsibility and they will make fewer (or smaller) decisions.

--

TANSTAAFL: if you pay for an outsourced service, at scale it will cost more than doing it yourself.

Simplest example: if you need the full scale, owning a datacenter full of servers is cheaper than renting large amounts of DC to put your servers in, which is cheaper than renting managed servers, which is cheaper than renting dedicated virtual machines, which is cheaper than renting spot-instances of VMs. Most companies do not need that full scale.

From:

laurion

I'm somewhat minded of the old adage about done right, done cheap, and done quickly: pick two.

From:

jducoeur

More or less, except that I no longer actually believe in the "done cheap" part. Indeed, that's another of the things I want to encode into one of these Laws if I can find the right metaphor: you most often *cannot* make the project move faster by throwing more money and programmers at it -- if anything, that often slows things down.

(I suspect the right metaphor has something to do with relativity, and the optimal number of programmers for a project being like the speed of light, but I'm still playing with this one...)

From:

jtdiii.livejournal.com

A project at risk gathers management attention and a corresponding increase in overhead costs.

Management always wants to know more and will burden an at risk prohect with additional reports and briefings such that it will become even later as the project leads are spending all their time briefing management, not helping to fix problems.

Edited Date: 2016-05-12 10:31 pm (UTC)

From:

jducoeur

So sad, so true...

From:

mindways

Brooks' Law ought to be formulatable as something which already has velocity to which you're adding standing-still weight - an inelegant version might be, "A late project adding engineers is like a speeding car throwing out grappling-hooks to snag additional cars [engines?] from the side of the road". I'm pretty sure a better metaphor is possible.

From:

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?

From:

jducoeur

Copying Ferd's point from the Facebook side of this thread, for my records:

"My suggestion ... your axioms, which are good, still only address execution. The first and greatest challenge for a startup is conceptual, exactly what capability and in what form will you bring to market? Much of the churn in early stage companies is indeed from specs changing, but they are changing because the business questions were never settled and the organization is adapting or compensating. Too typically the adaptation happnes in haphazard fashion.. I guess my point is, without clarity on the business side and awareness that evolution/adaptation are necessary part of the process, no Project Mgt model will give good results."

This is an extremely important point -- the single greatest predictor of startup failure, in my experience, is when the company starts to "thrash" its business plan. Indeed, the greatest failure I've worked at was the company that changed its business plan repeatedly -- it's probably not accidental that the same company never had a clear vision of the product, and never had anyone really in *charge* of the vision, with the result that we were all moving in slightly different directions.

As CEO, your job is Leadership. That doesn't have to (and shouldn't) mean bull-headedness -- it's quite common to find that a pivot is necessary at some point -- but you should have a clear vision about the business plan and a clear *direction* for the company (even if it tacks a bit as reality sets in). And you need to make sure that *somebody* (maybe you, maybe someone else) has the right and responsibility to translate those business requirements into product requirements in a clear and reasonably consistent way.

I should note that one *big* win about this annoying process of starting to raise funds is that it has forced me to pay more attention to Querki's business side. That, in turn, has led me to focus more specifically on Querki as a *community* tool first and foremost -- while it is and probably always will be good for personal projects, I think we're going to prioritize making sure that it really sings for communities and small businesses. That's what makes most sense for Querki as a business, and it's where I believe the need is sharpest...