Managing Programming for CEOs Part 2 – Done is a Four Letter Word

Bill Clinton had a problem with the meaning of “is”.  The meaning of “done” is much more ambiguous – and the source of many problems in managing development projects.

If you’re the CEO or are ever going to be, you’ve got to know when things are going to be DONE.  Nothing else matters; you can’t sell or use half done or 95% done.  As I blogged the other day, “95% done” is programmer-speak for the remaining 5% will take 95% of the total elapsed time.  You are asking for trouble if you try to manage by the percentages.

But what do you mean by “done?”  You may only mean ready to take to the DEMO Conference to attract potential investors.  You may mean ready to scare the competition with at a tradeshow, ready to test user reaction to the UI, or ready for beta testing by a few selected users.  It’s legitimate to mean any of these things when you say “done”.  But what’s critical is that both you and the development team mean the same thing.

Just to add to the confusion about “done” is that there are a bunch of other “dones” in programmer-speak – code-complete, feature-complete, alpha-ready etc.  Ignore these.  They have no value in telling you, the CEO, when the thing is actually going to reach whatever doneness you are interested in.

Having agreed on a definition of “done”, you then want to ask on every occasion when the project is going to be in that state.  There is only one answer to that question: a date.  Anything else anybody tells you is just blowing smoke.  The date is what you want to know; insist on hearing it at every opportunity.  Don’t be lulled by any yardsticks like “halfway there” or “right on schedule”.  Just the date, please.

OK.  So you insist everybody speak in dates.  Now how do you know that everybody isn’t just giving you the date you want to hear?  That will happen because you’re known to have such an awful temper when you hear anything you don’t want to hear.  And, in fact, you don’t want to just smile and be pleasant when someone tells you that the Christmas version of the web site will probably be done for Easter.

This is where milestones come in.  I like to have something I can touch from each team a month after a project begins and at least every two weeks after that.  You need to insist that each project plan longer than a month include a list of TESTABLE milestones – ideally something you can test yourself, at least something that can be demonstrated to you or your delegate. 

You will be told by the engineers that the project doesn’t lend itself to this methodology, that you will slow things down by creating these artificial waypoints, that they can tell you on a biweekly basis how far along they are without this.  This is not something you can afford to give in on.  Accept no substitutes for testable milestones. 

Where you do want to be reasonable is in setting the done date.  No matter how lenient you are, in fact, the date will eventually prove hard to meet for a number of reasons I’ll cover in another post.  But if you start out unreasonable, you will be the only person who believes in the date and you will have an unmanageable project.

OK.  You have milestones; now a milestone is missed.  You will immediately be told that the time can be made up elsewhere.  It can’t!  It is a rule of development that a project which is late keeps getting later.  Projects never make up lost time.  You now need to ask for the new done date.  If it’s not later than the old one, someone isn’t being realistic. Once you have a new done date, it’s time to make the hard decisions.  Your alternatives are:

1. Suck it up and reschedule whatever depended on the old done date.  Note that you can’t reschedule DEMO, major tradeshows, or public holidays.  You’re either you’re in or your out.  Maybe you can get half your money back.
2. Add resources.  In fact, this rarely works.  Programmers will tell you that nine women can’t make a baby in a month.  If there were truly independent tasks which were scheduled sequentially because of resource limitations and which are on the critical path, then, perhaps, timely application of more people will help.  It’s a long shot but sometimes worth a try.
3. Cut features.  This is by far the best strategy for making a schedule.  Every new feature not only takes time, it also adds to the risk that it will break some other feature.  Development time increases exponentially with the number of features.  Removing features can save schedules.

If schedules are consistently being missed, fire the development manager.  He or she may have been a super star; he or she may just be having a bad season.  But, in this respect development is much like a sport, he or she who isn’t delivering must be gone.  It is very possible that the fired manager, like a fired coach, will be a star elsewhere.  That’s fine; let’s hope so.  But you can’t stick with a manager who can’t make schedules. 

The fact –probably true – that you didn’t want to hear that the schedule was unrealistic is not an excuse after the fact.  Development managers owe it both to you and the engineers they manage to push back on unrealistic schedules before they commit.

Even when Microsoft was up to 10,000 people, Bill Gates personally reviewed every significant product release.  When he heard an estimated schedule, he didn’t like he could be quite harsh: the mildest thing he would say is that he could do it himself in VB over the weekend.  The mangers who told him what he wanted to hear survived the meeting but significantly damaged their careers when they didn’t deliver.  The brave ones said things like “We’re not as smart as you” or “Are you available this weekend?” but didn’t back down on their estimates.  If they were DONE anywhere close to schedule, they had very good careers.

Part 1 of this series is a phrase book of programmer-speak.

Part 3 is features that kill projects.

Part 4 is about great debuggers.

I’ve also blogged on how programmers can manage CEOs.

Part 1 is on managing non-technical CEOs.

Part 2 is on the even harder job of managing technical CEOs.

Comments

[Mark Mullin]

An old saw goes
'Writing software means never having to say you're finished'

By far the single biggest problem I've _ever_ seen in software development is that the management don't know Lord Westmoreland's law

When it is not necessary to do something, it is absolutely necessary not to do something.

Just because the product is malleable doesn't mean it should be. Hitting milestones means hitting concrete targets. Fuzzy definitions lead to fuzzy targets. Before a project has any dates set, get a concrete list of benefits that marketing wants to sell (or can be sold internally in the case of enterprises), identify the features that produce those benefits, and aim for that target. Change anything, recalculate everything. It's best to learn how to outstubborn a mule - the customers will want new things, the developers will want new things, and the whole thing will become a hopeless muddle if that happens

[Eirij Qureshi]

The problems pointed out by the author are absolutely true. However, why these problems occur is the real question. It's not just that the engineers are not truthful or they don't know how to do their job. The reason is a weak old process that the company uses, which doesn't allow the engineers to generate accurate timely reports. Therefore, they have to depend on guess-work to satisfy the enraged managers :).

Being the CEO of a company, a person should know better than just to impose a half-baked idea of iterative development on the team.

Switching to a better process is a good solution, but this is just my point of view.

[Coty Rosenblath]

I have been a developer. I have managed developers. I have not been a CEO, but I have watched a number of them make all the mistakes this post describes and more.

Every software CEO (and development manager, and product manager, etc.) out there should read and reread this post. If you are not looking at a running application to determine the status of a software project, then you really have only yourself to blame for delay and/or failure. Any developer or development manager who resists being measured strictly by running code should be fired. If you're really lucky, your development team should be asking you to come look at what they have working.

Don't let yourself be snowed by technobabble and obfuscation. By no means accept any sort of chart, or module count, or the like as a measure of "done". You wouldn't measure anything else in your organization (I hope.) so indirectly. There is no reason for software to be any different.

In the long run, your developers will thank you. My experience is that developers are often frustrated by managers who are over-promising and obscuring status. Your best developers (and, ideally, your only developers) will relish the opportunity to make the status of the project objectively clear. You will be doing them a service. They want to deliver. They want to ship. They know what has to be done. Help them.

[Patrizia]

Done is a four letter Word...

"Still something to do" is a four words statement.

There are two terrible misfortunes in life.
The first is having a goal and not achieving it, the second, even worse, is to achieve it.

I hate having nothing to do, even worse, having nothing new to do.

I love planning my tomorrows and then having to re plane them.
Sometimes it looks like that my yesterdays walk with me and my tomorrows with somebody else. I just cannot see enough, or better, I see too much.

Imagination is something that haunts the people without a present.
At least they can think of a future.
It is like religion or faith.
The less you have in this life, the more you want to believe.

Dreaming is something that haunts the people without a future.
At least they can live what they do not have.
A reality which is better than any reality, because it is unreal.

"Bill Gates personally reviewed every significant product release. When he heard an estimated schedule, he didn’t like he could be quite harsh: the mildest thing he would say is that he could do it himself in VB over the weekend. "

The dreamer is a lucky man, because he can live what the normal man will never be able to live.
The important is that his dreams never become reality...

patrizia@worldonip.com
http://woip.blogspot.com
http://www.worldonip.com
http://www.easymediabroadcast.com