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.