Time to Market Strategies:
How to Keep Your Job by Running Successful Projects

By:  Erick Nelson
Last Updated:  August 28, 2004

"The way to get work done quickly
is not by hurrying, but by thinking clearly."

Abstract 
When given a critical T2M project, the one thing we shouldn't do is to do what comes naturally:  use the normal methodology, hire more people, make them work longer hours, and shoot for "just good enough" results.  This is a recipe for failure.  Instead, we should pay extra attention to specialized project management approaches, and consciously and intentionally make the appropriate tradeoffs. 

Preface
I believe that there's a great paradox here.  The ideas presented here are demonstrably true, but they also run counter to the normal company culture.  I therefore consider them (though they are not new) to be revolutionary and highly, highly controversial. 

Introduction

Over the past several years, my projects have been successful - completed on time, under budget, and virtually problem-free.  Most of them have been date-driven, Time to Market projects.  One of the reasons, of course, is that I was able to work with excellent analysts and developers, and they are deserving of much thanks.  I would like to think that I have a certain talent for this kind of work, and hopefully that has contributed as well.  But that's not it.  I think the crucial element has simply been that I applied a sound project management philosophy.  This foundation was established by certain excellent books on the subject, especially Maguire's Debugging the Development Process.  The rest has come about through both positive and negative experiences, along with conversations with developers and other project managers.  [1] 

I should point out that many of the lessons I have learned came through hindsight - looking back at a project, and kicking myself for mistakes I made (vowing never to make those mistakes again).

Here's how this web article came about:  I started writing down my notes in June, 2001 when I was given a big Time to Market (T2M) project, just so I could gather my thoughts and decide how to run the project.  As various things happened in my projects over the last couple of years, I've added material as I encountered each challenge.  Here I share these insights, and welcome comment and critique, so that we may all keep our jobs by running successful software projects.

But First, Why "Time to Market" Issues?
As I hope will become clear as you read this, T2M considerations bring project management, as a discipline, into sharp focus.  There are two types of projects that put tremendous pressure on the normal process:  (a) those for which absolute accuracy is essential (NASA, life-support), and (b) those for which making the date (successfully) means everything to a company.  

Time to Market projects are obviously the latter.  When you're running a normal project, there are various issues which can be avoided, problems that can easily be mitigated, and methods which admit a large tolerance of error.  But when T2M is the focus, you find that these issues must be faced squarely, the problems must be overcome, and there is little forgiveness to be found for failure.

And so, a lot of the really interesting issues are found in T2M:  they are often the normal issues simply made larger than life.  And if you can manage this kind of project well, handling regular projects will be a piece of cake.

Schedule-Driven Projects
There have been several definitions of "Time to Market."   A common denominator is quite obviously the emphasis on schedule-driven planning.  We will discuss some of the issues involved when undertaking a very aggressive Time to Market project.

Deadlines and Due Dates
A plausible definition of "deadline", cited by Don Wessels, is "a date that, if it is not made, results in serious loss to the company."  It's a date that simply must be met.  A "due date" on the other hand is a target date - still important, but not absolutely essential.  

There are various reasons for creating a deadline, including:

  1. The company will go out of business if the date isn't met
  2. The product is inherently date-driven - e.g. Republican National Convention, if it's not done on time don't bother doing it; or Y2K, if missed, results in major problems 
  3. The company is striving for first-to-market status - or trying to minimize 2nd-to-market gap
  4. The company stands to make or lose a significant amount of money for each time period the product's delivery extends past the deadline.

How do projects actually get accomplished quicker?  That's the issue. 

Don't Do What Comes Naturally 

For most managers, the knee-jerk reaction to an extremely tight schedule is four-fold:  (a) use the existing methodology, (b) hire more people, (c) make them work longer hours, (d) accept "just good enough" quality.  The major point of this paper is that this is not the approach to take.  We should not just do what comes naturally.

Models
If you are working in an Industrial Revolution style environment and want to drastically increase productivity, just bring in more workers and make them work longer and harder.  You can thus move more material from A to B, put together more widgets, and dig more and longer ditches.  And if you want to maintain this productivity over time, you can simply throw away the old tired people, and bring in new fresh troops.

But will this work in a technical, information-oriented environment?  I don't think so. 

Intellectual Capital
I have to admit that all the talk I've heard about "intellectual capital" has always seemed like pretentious hype.  I always said, "It's not like this is rocket science."  Real "intellectual capital" is represented in Russell and Whitehead's Principia Mathematica, or Kant's Critique of Pure Reason.  Ok, maybe the architects of microprocessors might represent "intellectual capital", too, but application programmers?

It was only in the midst of a large effort to integrate two computer systems did I understand that intellectual capital really is involved in our work.  Those who didn't understand the systems spent an inordinate amount of time discussing the wrong things, trying to find out how the systems work, and basing decisions on assumptions that later were proved to be false.  The people who really understood how the systems worked were worth their weight in gold (and more).  In the same way, the people who understood how to get clarity with their projects and move things forward enjoyed a terrific advantage over those who tried to just wander through the mazes of meetings and conference calls, hoping for the best and fearing for their jobs.

And so, the victory doesn't go to the strongest, or the swiftest, or even to him who perseveres.  It goes to the people with knowledge and wisdom - and consistently clear thinking! - that's the one who gets the job done.  When thinking becomes fuzzy, the whole process becomes compromised.  This is the root assumption underlying what is to follow.

Pressure the Developers?

Steve Maguire, author of Debugging the Development Process, was a project manager for years at Microsoft whose role was often to turn around failing projects.  Microsoft is known for its culture of intense work and long hours.  Maguire says:

"As I've said, for several years at Microsoft, my job was to take floundering projects and make them functional again.  In every case, the team members had been working long hours, seven days a week, in a desperate attempt to catch a ship date that was moving ever further away.  ...
    On my first day as the new lead, my initial actions were always to put a stop to the long hours and start looking for the causes of the slipping schedule.  I would walk down the halls in the early evening and kick people out.  'Get outta here.  Go have a life.' ...
    It might seem logical that having the programmers work all of those hours would enable them to finish the product sooner.  Unfortunately, it doesn't work that way, not in software development."  (Debugging, p 153, 156)

Exactly why doesn't it work that way?

Productive Hours
Long hours don't always equate to long productive hours.  This was especially evident at Microsoft, Maguire tells us.  Even though developers were physically at work for 12 or more hours a day, they were often forced by this circumstance to take care of their personal business within that time frame.  They worked such long hours that they felt justified in playing foosball, taking various breaks, etc., and he figured their net productive hours per day was something like 9.  

Mental Fatigue and Diminishing Returns
Various project studies have indicated that actual productivity starts to diminish at around 8 hours a day.  I don't know why 8 is the magic number.  But, even in the short term, the 9th, 10th, and 11th hours are increasingly less productive.  

But that's not the main point.  The point really is, simply, that mental fatigue creates a situation where our thinking becomes muddled.  Muddled thinking results in poor choices and flat-out mistakes.  For programmers, those result in sloppy, convoluted, or error-prone code.  What is the point of intentionally introducing poor work?  And what is the point of pumping out increasing amounts of poor work?  Every hour spent producing poor code costs more than an hour to correct it.  And if the correction process itself is a victim of mental fatigue, the problems obviously are compounded.

While most programming errors don't result in mission-critical tragedies, some do.  I have seen programmers spend months cleaning up billing mistakes that were caused by a relatively small programming error.  And the clean-up usually involves not only fixing the error, but going back and recovering from the error - in this case, making laborious invoice corrections.

For managers, mental fatigue results in poor decisions - at several levels.  One manager has  gone round and round about some issue, and finally feels she just has to put a stake in the ground; so she makes an arbitrary decision, just because she's fed up and can't stand the haggling.  Somebody asks another manager a question, and he just says anything that comes into his head because he just can't face going through all the details and analysis - and what was said becomes "fact" with a life of its own.  Yet another manager is perpetually crabby and alienate one after another team member, along with other managers.  Or a manager gets so anxious she gets too paralyzed to make a move.

Frenzy and Diminishing Returns
I am absolutely convinced that the number one key to project success is clarity.  Confusion is our enemy (more on this below).  Confusion causes mistakes, misunderstandings, ambiguity, false starts, doing the wrong thing, correcting the wrong mistake ... the list is endless!  Pressure causes frenzy.  Frenzy causes confusion (and other effects, mentioned below).  

Pressure and Short-Cuts
I was once told by my manager, in a commanding voice, that I could NOT go home that evening until I finished a certain change to a Windows help file.  I barely had a clue about how to make the changes, but was muddling through.  I was stuck on one task, though.  I knew that to do it the right way meant I'd have to look up documentation, which may or may not exist; or probably ask people how to do it - and those people weren't around.  This could take literally days.  OR ... I could clone a section of code and tweak it and go home.  I did the latter and went home on time.  This came back to bite us all down the road, and I eventually had to fix it anyway during a much more crucial part of the schedule.

The point is, how many short-cuts do we make on our own due to pressure (even secretly) to hit the date?  Remember, programmers will be touching this code over and over for years to come, and the long-term prognosis is not good.

Threats
One approach that is unfortunate is the executive temptation to try to achieve their goals through mandate.  One executive told us in a meeting that the card key works 24-hrs a day.  Another executive pointed out sternly that there are not five, but seven days in a work week.  In both instances, many people spent more time debating the work week issue than actually working on the project!  Since these directives were not actually put forth in writing as formal requirements, but only presented as threats, they weren't actually followed (thankfully).  Then served only as a huge distraction, ironically undercutting the executives' own desires for heroic effort.

Getting Tough
As an important caveat:  This is not to say that you always have to be the nice guy.  You should get tough when you really need to, but not as a matter of daily living.  A guy I know - one of the nicest, sweetest guys I've ever met - is in the Army Reserves.  He just (Dec, 2003) got called up to active duty in Iraq.  I assumed that he was a mechanic, or regular foot-soldier of some kind.  Turns out he's a staff seargent.  I was amazed.  "Do you yell and scream at the guys?" I asked.  He quietly said his style was different than most, but that if the situation called for it, yes he could yell really loud.  He said, "Sometimes, you've just got to get in their face."  In fact, as he described a recent situation, I could see the fire in his eyes, and a whole different side of him became apparent.  He could really bring it.

Some leaders, managers, and executives yell and scream whenever they hear something they don't like, or when they want to get something done.  But that doesn't show leadership, or even toughness - it shows that they can't handle their own frustrations.

"But wait", you say, "Bill Gates is well known for blowing his top, berating his employees and screaming at every opportunity!  And he's the richest man in the world!"  True.  But I'm convinced that Gates is not the richest man in the world because he yells and screams, but because he's smart extremely focused, understands both the business and the technical side, and is willing to relentlessly pursue his dream.  He could have done that without screaming - and probably had more fun in the process.

Emotional Reaction to Pressure
These are many and varied.  For some people, who seems to thrive on this stuff - and only for the short term - such pressure can stimulate them to do their best work, give them something to achieve, yielding intense focus and commitment.  But I think this factor is vastly over-rated.  Think about it - what kind of people thrive on this?  (a) those who are type-A achievers anyway, or (b) those who require a kick in the pants to get motivated.  The first group doesn't need this motivation, and the second shouldn't be working in your organization anyway.

For the good worker, intense time-pressure over long period of time can only be bad.  Besides mental fatigue, with resulting problems (just mentioned), there is the problem of actually dealing with emotions themselves.  I have witnessed first-hand, on a troubled project for which I was a developer, what happens when the programmers know that the project is poorly run.  They spend maybe half their time rehearsing over and over to each other how stupid the project is.  I distinctly remember that just to manage this tendency in myself was a huge emotional task.  (This is of course difficult to quantify, because it all occurs under the hood ... it's not as if people can charge their time to "Whining.") 

Beyond that, these reactions may be seen:

Irrational Pressure Breeds Failure
Here is an unsolicited quote from a friend who was an excellent developer in a very high tech environment.  He's the kind of guy who actually invented his own operating system in his spare time (when he had spare time) just for fun.  He put up with the craziness for awhile, but finally just moved on to a better environment.  The loss to the company was significant.

We did Z8000 simulators to where we could run the same binary code, on a PC!, that would run on an Army vehicle, we did data collection, we did battlefield communication simulations, etc. 

All I can say is this -- if life is getting "high pressure and irrational" at work, and it stays that way for extended periods of time, then things need to change. Some people live to work. I used to do that -- my whole purpose for existence was to work. The boss would make up hard-to-meet deadlines, get the customer to like it, commit us, then we as worker bees pulled rabbits out of hats (almost literally) to meet the schedules and get things done. Yes, it was challenging. Yes, it pushed our limits.  Yes, it proved we could do more with less. But then, the pressure was on to outdo ourselves just a little more than the last time. Finally, I was working quite a bit of overtime, terrified of my boss, exhausted, and social life out the tubes.  I decided to change.  Let me tell you, the work was cool.  But we were driven to the ground.  [name witheld] was a small company, with an engineering division of maybe 10 people or so.  Within 2 weeks, 5 of us turned in our notices, 4 of those were within 1 week. 

No more. I work to live. I try to get work done, but when life calls, work will take a second priority if necessary.  Sure, there are still deadlines. Sure, there are still crunch times. I step up to the plate as much as I can to do that. But they tend to be controlled where I am at -- and that says a lot.

Don't Run Around Just for the Sake of Running
In situations where the direction is unclear but a super-aggressive date is imposed, the natural reaction is to do something right away - do anything ... and do it all in a hurry.

Once, my wife and I were driving out of our apartment complex, and the lady in front of us started to turn left into traffic.  A motorcycle hit her broadside at 50 mph and the guy flew through the air like a man shot out of a cannon, with his arms at his sides.  He landed on his face and chest.  It was horrible.

I jumped out of the car and ran up to him.  It was all I could do to resist the urge to say "Are you ok?" - All I could think of was to run for help.  So I took off down the street, and then immediately realized that a phone was probably closer off to the left; then I thought I could get to a phone quicker in a different direction.  I literally ran all the way around the guy as fast as I could - maybe even twice - in a frenzied attempt to do something.  Then I sprinted four blocks down the street to the fire station.  

I came back drenched with sweat from the exertion.  Meanwhile, my wife had turned off the car, got out and walked about five feet to the guard booth, called 911, and helped the lady.  Who had worked harder?  I did.  But who got results?  She did.  In a project where people are running around in circles, a lot of energy is expended but there's often not the luxury of having one clear-headed person to make up for it.

Don't Cry Wolf
Sometimes the pressures of aggressive projects can make it seem as if the sky if falling.  Avoid the Chicken Little Syndrome if at all possible.  And save your emergency chips for when they're really, really needed.

Micro Level.  The pressure of aggressive targets sometimes gets to the project manager.  But be careful how you pass that pressure along to your team.  One Friday afternoon, my boss called me into his office and asked me to do some research and a follow-on write-up, and stressed that this had to be done absolutely as soon as possible.  Working the weekend would not be discouraged (wink).  Impressed with the severity of the situation, I cancelled my family's plans for Saturday and spent most of the day preparing this document.  I sent it proudly to my boss on Monday.  He waited for over two weeks to even look at it.  A true Dilbert moment.  Do you think I would be likely to rush to his aid the next time?  Not.

Macro Level.  What happens when a business sponsor strings together several high-profile T2M projects in a row, with the same project manager.  With the first one, you leave it all on the court, as if your very life is at stake.  At the end you're in some relative state of burn-out.  What if the second project is worth twice as much as the first?  Is there enough gas in your tank?  Running on empty?  Make sure you don't sacrifice a truly important future project for a fairly important present one!

Choking
In 2002 the Seattle Mariners looked like a sure winner; but in the second half of the season, they started to fall.  If "trying harder" was the necessary ingredient to success, they would have won it all.  But there were times when trying harder simply meant pressing.  

Michael Jordan was once asked in an interview how he could always rise to the occasion when the game was on the line.  He replied that most players actually performed worse under extreme pressure, but he was able to ignore the pressure and play the same as always.  Thus, he didn't actually raise the level of his game; it just looked that way.  

While there are incentives and dis-incentives that help the team focus on the goal when applied rationally and in moderation, extreme pressure is almost always self-defeating.  It takes a Michael Jordan to overcome it.

Don't Plan to Lose
It's inevitable at the final stages of a failing project that this thing just won't work.  At that point, I can assure you, nobody wants to be identified as the cause for failure.  It's only human nature, I suppose, to try to cover yourself and deflect blame, if possible.  That's bad enough, but I've seen this phenomenon even at the early stages of a project:  a project manager is so concerned with not getting blamed for failure that this becomes his ruling principle.  And so, he'll accept unrealistically long hours as long as it's someone else's responsibility to get it done; he makes sure that he can identify his dependencies expressly for the purpose of saying, "We were ready, we were just waiting on so-and-so."  

I was once advised, when pondering a dependency on another (in this case, troubled) project, "This is their work; just hold their feet to the fire!"  I realized that there feet were already charred to a crisp and that this was just a way to blame somebody else.

But we want our project to succeed!  Then, there's no blame to worry about.  It seems ridiculous to come out and say we want to succeed, but I see this goal sometimes missing from the real day-to-day world.

I'd Rather Win than Look Good
I love a quote from the basketball movie White Men Can't Jump - "The problem with you is, you'd rather look good than win."  There is a sense in which a manager with a team working 12-16 hour days looks great:  everybody is obviously working hard, digging in, heroically sacrificing their personal lives for the common good.  If they are missing their dates, it isn't for lack of effort!  I believe that, at some level, this motivates some managers to crack the whip regardless of the effects.

I asked a friend, who was a developer for a high-pressure project in which they routinely spent long hours, how that all worked out.  She is young, energetic, and resourceful.  She said that Monday through Tuesday went fine; Wednesday was ok.  She just would go home late, and then straight to bed.  By Thursday she was getting tired, and carried around a lot of worry about the things she couldn't get done at home.  By Friday, she had a hard time getting up in the morning and dreaded dragging herself in to work.  By weekend, she was too burned out to do much of anything.  By Monday, she was much fresher (but not quite as fresh as she'd been the week before) - and the cycle started again. 

I asked her what they spent the most time on.  She said "fixing problems."  I think there's a correlation.  Then I asked her if she could have completed the same work in a 40 hr schedule, and she admitted she probably could, and maybe better.

On the other hand, the team that makes its dates in a normal 40 hr work week is open to the accusation of padding the estimate, working the system.  So, ironically, the manager of the failing project is sometimes seen as a success, while the manager of the successful project is not.  But - all things considered - I would rather win than look good.  Or, more accurately, I would rather look good by winning.

Hire More Developers?

This is such a common fallacy that it's been pointed out by virtually every project management book I've seen, going all the way back to the 60's, so I'll just touch on this.  It's simply not true that more programmers can necessarily get more work done.  Several reasons:

Lean Teams
Historically, lean teams have often produced the most, and best work.  There is, obviously, a right number, or at least right range, for each type of project.  The point here is that simply throwing more bodies at the problem doesn't automatically solve it.

Make it "Just Good Enough"?

For some critical T2M projects, especially where first strike means success, "just good enough" quality is built right in to the project requirements.  This can mean different things in different scenarios.  Naturally, if missing the delivery date means that the company will go out of business, the (very appropriate) goal may well be "do the best you can, and put it in on time whether it's right or not."  If the reason for the deadline is not as drastic, the company will survive only to deal with the risks and losses.

What is "Just Good Enough"?  
For NASA and hospital life-support systems, "good enough" is something very close to 100% perfection.  No significant failure can ever be tolerated - people's lives are literally at stake.  But to say (as I've heard), "This is not NASA - we work under the 80/20 rule" doesn't tell us much.  What's good enough for one person appears as irresponsible work to another. 

Unless the date is so drastic that almost anything is "good enough", we have a choice to make at the beginning.  We must (ironically) burden the project with an additional up-front task:  defining what's good enough.  In my own thought experiments on projects, it has been surprisingly difficult to provide such a definition.  The decision almost has to go back to the project sponsor - and then we're dealing in hypotheticals:  If this happens, is this ok?  is that ok?  would that be close enough?  

Or, alternatively, we could handle these in a one-off manner, continually peppering the business sponsor with questions as they happen to arise.  This, of course, is the least favorable alternative to a sponsor who happens to be a senior executive!  Another  problem with ad hoc judgments is that of dependencies:  our seat-of-the-pants decisions may presume future events that don't come to pass.

Don't Expect to Fix it at the End
There is an old music-recording joke.  Something isn't right on a basic track, and they say "We'll fix it when we do the overdubs."  It's too hard to fix when overdubbing the tracks, so they say, "We'll fix it in the mix."  During the mix-down the engineer looks at the artist and says, "Ah, we'll fix it at mastering."

For a project with an absolutely hard date, that has fallen behind, everything is fixed at mastering.  What I mean by this is that the programmer - instead of having stable code with only some dependency issues to work out - is still coding, right up until the time of delivery.  What happens then?

At this point, everything becomes a work-around.  Have you ever sat in a meeting filled with frustrated people?  How productive are those meetings?  Why the frustration in the first place? - because these people are competent professionals who are accustomed to success.  They don't like being put in a position where they are bound to fail.  They thrash around, trying to make it work.  Sometimes, people pull heroics out of their souls - but, candidly, I have not found this to be the rule.  I have seen these tensions brings out the worst in people, not the best.

Young programmers sometimes expect to work round-the-clock at the end of a project.  This is simply a juvenile approach - it's just like the lax student who pulls an all-nighter in order to pass a test.  That may work for isolated school situations (although, I've seen that approach fall short), but when this is a project that means thousands or millions of dollars, planning to do this to make up for lack of results early on is simply asinine.

Crappy Code Actually Takes Longer
There is a modern urban myth that you can write a program faster if you write whatever code comes into your head, structuring (or failing to structure) as you go.  I call it "Breathless Coding."  I agree that it gives the subjective impression of speed, even exhilaration - dropping all encumbrances of bureaucracy to "Just Do It."  But there's a problem with this method that many professional programmers have discovered through trial and error.  Once your program reaches non-trivial size, the code becomes increasingly difficult to follow, and thus to correctly extend.  In fact, when I was first learning programming I found even a single day after writing a program that I could hardly follow my own code!  And so the problem is more severe than a simple maintenance issue (although that is serious enough); it is actually an immediate issue.

To give an example:  I was given a failed project to turn around.  The project was losing $20k every day it wasn't in.  On the first day I was informed that the previous PM had asked the project sponsor to test the screens, and they continually crashed.  This had happened more than once!  One of the first things I did when I took over was to look at the code, and it was obviously very poorly done.  I set up a meeting with the developer and gave her a whiteboard talk on why structure was important, logical levels, the whole shot.  When I finished, she said, "That's how I wanted to do it, but he told me not to."  It turns out, the PM had stood over her as she typed, demanding functionality, and she just typed whatever came into her head.  When she asked to have some time to think about it and put it into shape, he gruffly replied, "It's good enough for now.  We don't have time!"  And so, she made one change after another.  Every time she fixed a problem, she created a new one.  It was never-ending.

I told her, "I'm going to say something you will probably never hear again.  I want you to go through all the code and clean it up.  I don't care how long it takes.  Just make it simple and straightforward."  Two weeks later, she had a strong product.  This week saved us months of torture.  If you want any kind of correctness at all, even 80/20, writing crappy code will always take longer than writing good code. 

McConnell calls the phenomenon "Code like hell."  When you do that, you are rewarded with hellish code.

Weighing Different Kinds of Defects
Programming is not so simple that you can easily quantify exactly how 'good' or 'correct' a product is.  One reason is that there are different kinds of defects.  The two major kinds are black-box defects and white-box defects.  

Black-Box.  If you treat the system as a 'black box', only looking at inputs and outputs, a this kind of defect is any incorrectness in output that occurs.  The temptation is to say that x% error is acceptable.  But even in black-box testing, you have to say which percentage error is acceptable for each kind of defect: 

White-Box.  The is more to correctness/error than simply looking at black box outputs.  White-Box (or clear-box) testing opens the process up to inspection.  Are we willing to allow that the internals can be absolutely anything, just so long as the outputs are (mostly) correct?  The temptation, again, is to say "sure" - all I care about is results.  

But think about the implications of having a messy interior.  For one thing, the only way you know that the output is acceptable is to test every possible combination of input/output, which is impossible.  Second, what errors will be introduced with every round of changes to the product?   I'm told of an outsourcing company who produces black-box-correct code.  But the structure of the code internally is so convoluted that even they can't make changes to it.  It is a house of cards.  When changes are required, they actually re-code from scratch.  As a one-time effort, this price may be acceptable if the rewards are sufficient - but not often.

Long-term Effects
Another problem is that the system must be maintained.  If the system does something different than it should, this flaw eventually has to be corrected.  Worse, though, if "just good enough" determines the coding decisions, we create an instant "legacy system." - a mess which must be tolerated for years to come. 

There are indeed times when throw-away code or sub-systems is a legitimate approach - but it at least must be entered into with eyes wide open. 

Legal Implications  
There are, possibly, legal issues to consider, as we faced when changing a billing system.  Fraudulent billing is not an attractive prospect.

Room for Error
The final problem is Risk, with a capital 'R'.  If I have the luxury of building a system that is well-conceived and well-executed, and I fall slightly short of my goal, I still have a good system - maybe an excellent one.  

But if I am shooting for only "just good enough", I have two potential problems, which carry significant risk:  (a) I may create the intended system, but our notions of "just good enough" were inaccurate - so it's definitely not good enough; or (b) I may fall short of my intentions, and since I'm working with no margin for error, I'm again not good enough.

What We Should Do

While the things that come naturally to mind are often to be avoided, there are still many things that we can do to bring a project in on time.  On one large project, the PM was faced with an impossible date with virtually no resources.  He told his boss that he didn't mind working hard, making sacrifices, and overcoming obstacles.  But his plea was simply:

Don't set us up to fail!
Give us at least a chance to succeed!

What are the strategies that will give us a chance to succeed?  There are two broad categories:  (a) do the normal things extremely well, and (b) use T2M strategies and trade-offs.

Do the Normal Things Extremely Well

First, it's clear that there are many general project management techniques that apply perfectly well to T2M projects.

Excellent Project Management
It should go without saying that excellent project management is essential for T2M projects:  not just ok, not just good, but excellent PM.  I refer the reader to Steve Maguire's Debugging the Development Process, which lays down some excellent principles and approaches.   

Confusion is Our Enemy
The biggest killer of projects is simply confusion.  I will only address one aspect here:  wasting time.  It's obvious that you can do the wrong thing and have to go back and do the right thing.  It's also obvious that you can do the right thing in the wrong way, and have to redo it.  You can do the right thing in essentially the right way, but leave a trail behind you of ambiguities, missing information, and outright errors - leading astray the people who come behind you or work with you.

I have attended way too many meetings where the leader and/or team were confused about the problem they were attempting to solve.  They spoke at cross-purposes; they argued over the wrong things; they brought up red herrings.  Trying to describe something, they got so tangled up in their words that they finally fell silent.  One huge sign of project trouble is when you find yourself meeting week after week and discussing the same topics ... and saying the same things!  I can think of two projects that failed, and one that was seriously late, that suffered from this problem.

On the other hand, I have also seen a simple chart on the whiteboard take away all the confusion and bring some sanity to the room.  In all aspects and facets of the project, make things as clear, simple, and straightforward as possible.  

Keep it Simple
Probably the easiest first step at eliminating confusion is to always strive for simplicity.  Every additional complication not only adds to total complexity, but increases it by some multiplicative factor - sometimes even exponentially.  Some programmers revel in complexity - that's just how they are wired.  Let them work on your project, but don't let them do design! 

And remember that 'simple' doesn't mean simplistic.  You can't dispense with error-handling, for instance.

Go Looking for Trouble!
One of Maguire's analogies is that the project manager is like the scout driver for those flatbed trucks that move houses.  They go ahead of the truck, looking for obstacles, making sure there's clearance.  He says:

"I'm convinced that the main reason projects go astray is that the people running the projects don't spend enough time thinking about how to keep them running smoothly.  They don't anticipate problems and instead wait until problems show up.  By then, it's too late."  p 46

This subject requires a whole book.  Since Steve Maguire already wrote a good one, I'll just refer the reader to that resource.

Get User Buy-in
There are two kinds of problems I often see relating to getting user buy-in.  

The first is poor management by the PM.  All too often, the PM says "Ok, so-o-o ... what do you want?" and expects the business user to have thought through everything, analyzed the alternatives, and hand him/her detailed requirements.  Then, when requirements are given, the PM implements exactly that, and then wonders why the user keeps changing her mind!  A similar activity is simply the laziness of the programmer who throws questions over the wall and says "Well, I'm just waiting on the user for direction."  The correct approach is to help the user figure out what the very high-level business desire means for your systems.  

The second issue is lack of emotional involvement on the part of the business user.  It's just a fact of human nature - given the information-overload world in which we work - that you have a hard time caring deeply about something that's not (yet) real.  It's astounding what users can discover, and think of, when they're dealing with a real production system.  All the "Oh, we should have done this ... can you do that?" insights descends like an avalanche.  Why couldn't they have done that during the requirements and design activities?  I have joked that we should have a "fake implementation" phase, before coding, which would psychologically force the user to get into it emotionally.  Actually, this is one of the challenges of project management - it's part of the PM's job to work with the business user in such a way as to get the attention and emotional buy-in needed to think it all through and come up with a solution.

Get Team Buy-in
First, to get buy-in from the development team, I would advise you to rely on the carrot rather the stick.  In my experience, especially with high achievers, threats are counter-productive.  I told my boss once that I respond well to incentive plus clear goals, but I have two reaction to threats:  I experience either anxiety or anger; and I have to spend a great deal of effort managing these rather than focusing on the project.

Relying on the stick rather than the carrot operates on the assumption that your team members are essentially lazy, and will tend to do only what is absolutely required and no more.  Since, as we will see below, we'll need to rely on high achievers ('stars'), I would submit that this assumption is simply false.  High achievers are self-motivated, and want to do significant, interesting work.  And they are determined to succeed.  One developer I know once declared that what he wants from a manager is "Pay me a lot of money and get out of my way."  While this is overly simplistic, it does contain a truth.

The reason for the stick. of course, is to make it clear to all that this project is hugely important - we can't afford to let anything get in the way.  No messing around.  And that message needs to be made.  So how do we get buy-in in an appropriate way?  It depends on who needs to be impressed.  I'll assume that the business sponsors are emotionally focused, and so is the project manager.  This requires an entire book, but I think there are two types of elements, both of which are needed:

Tell the Truth
I know of a project manager who knew his project was way behind and failing.  He continually spun his project status to his boss, who (I am told) spun it on up the line.  The official story was that everything was ready, but waiting on other projects, waiting on the holidays, etc. etc.  The project manager was eventually fired.  

Another project, the one given to me to resurrect, had been run by a PM who continually lied about status, right up until the end.  And the end was harsh.

I'll give a third example.  This project was announced to be on track right up until the time of implementation (although it was riddled with problems).  The PM apparently figured he'd get the project in on time and handle all the problems as 'maintenance.'  When it became clear that he couldn't make the date even under those circumstances, he sent out emails saying it would be delayed two days, hoping against hope that he took take the work home and work around the clock to save the project.  On the second day, another email saying it would be delayed another day.  Then three days; then a couple of days; etc. ... and finally a couple of months.  

I learned a great lesson from that.  On my resurrection project, I had had to provide a schedule and estimate to the Executive Steering Committee even before I had understood the Requirements, based upon some assumptions about the project's status.  When, several months later, it became apparent we couldn't make that date, I figured out what it realistically would take, pushed the schedule back a couple of months, and took the hit all at once.  And that realistic date, we made.  And I got an award for that project.

The project sponsor has to make reality-based decisions.  If you have a problem, you have to bring it up - you can't just hope for it magically to go away.  If you made a mistake, confess it and take the hit as early as possible.  But it you try to spin, everybody who is counting on your word will be operating under false assumptions, to the harm of all.

Saying It's Impossible
Be cautious when evaluating the project - if you see that it's absolutely impossible, you can't stay silent:  you have to say something.  You shouldn't just go ahead and agree that you'll get done, somehow, some way:  you'll pay for it in the end.  But if you put a stake in the ground and declare flat-out that "this is completely impossible", then you paint yourself into a corner.  You run the risk of the following:

The project sponsor is a high-level exec, and puts his foot down and says by golly it WILL get done - and ON TIME!  You've already declared the task impossible, but you try to do it anyway, in order to retain your job (for now).

Now, you can't win.  First, you are inherently conflicted.  You've taken a stand that this simply cannot get done.  How can you try your best to prove yourself wrong?  There has to be a part of you that's holding back, wishing for vindication.

If you were correct all along, the project will indeed fail.  But no-one will exempt you from your responsibility.  They won't remember that you said it couldn't be done.  Do you honestly think the higher execs will sheepishly beg your forgiveness for forcing an impossible task down your throat?  No, YOU were responsible, YOU failed.

On the other hand, if you get really lucky and creative and everything falls right for you, and you somehow get the project in on time without disaster, then you've just proven to your bosses that (a) You didn't know what you were talking about, and/or are gutless; and (b) The way to get things done is to appy lots of pressure.

So, what is the right thing to do?  If the desired work is really impossible, then you have to substitute something for it that IS possible.  If you can get respected analysts and managers to independently agree that the original proposal can't get done, but yours can (and if this substitute accomplishes the core objectives or something very close to them), then so much the better. 

If you get to the point where you realize you are set up for failure, with no chance of success, then it's probably better to find something else to do than to go down that road.  It's a lonely one.

What We Should Do - Tradeoffs

If there is one major insight that I'd point to, it would be that there are special techniques which are appropriate specifically for T2M projects.  These go beyond, or even counter to, normal methodologies.  The somewhat radical proposal here is that we should not "do the same things only try harder" - but that we should do things differently.

A corollary to this is that these tactics actually put pressure on the company itself.  That's because tradeoffs are always necessary, and tradeoffs negatively impact the company.  Look for those tradeoffs below.

Extreme Focus in the Project
The most important tactic proper to T2M projects is relentlessly maintaining a clear, tight focus on exactly those things - and only those things - that further the project's goals.  Anything else - clear it away!  Again, this requires an entire book - Maguire is a good place to start. 

Make the goals precise and clear.  Exactly what is the functionality needed?  If some piece of work seems like a good idea but is not part of the target functionality, don't do it (at least, not in the T2M release).  

A great example to learn from is a developer on one of our Windows-based products that knew we had divided the functionality into two sets:  do now, and do later if there's time.  He was so in love with some of the optional features that he actually took the work home with him and did those things late at night on his own time.  I asked the project manager (I was the project lead), "How can we get mad at that?"  He said, "There's more to this than adding some features on his own.  Now we have more things to test and debug and maintain - that weren't part of the intended scope!"  They were nice things to have, but probably delayed the project.

Extreme Focus in Management
Dump some of the formalities.  Nothing should be for show, only for a purpose.  Long, regular status meetings and detailed status reports look like good communication, but can be huge time-wasters.  On a large project, all I asked for in weekly status was the number of hours booked toward separate work packages - usually four or five email lines.  And if anybody had a problem that needed my attention, they immediately emailed it to me in the course of their work and we dealt with it right there.

It should go without saying, but still is sometimes forgotten, that for the duration of the project, this is - in the business sense - the PM's reason for living.  Other interests, pursuits, and obligations, just have to wait.  I say "in the business sense", because it's counter-productive (besides being unfair to family) to try to do this 24 hrs a day.  What I mean is - no training, no participation (or at least minimal) in general company business (such as manager meetings).  For a significant portion of the project, you the PM are on the critical path.  Every hour wasted is an hour delayed.  Daunting, huh?

Politely say no.  I recently fell into the trap of attending a seemingly endless round of multi-hour (sometimes all-day) meetings, often with 20 or more people for a huge integration project.  (I've noticed it's often the case that the more people in the room, the less chance the conversation will focus on my concerns.)  99% of the discussion was useless to my project.  But I was required to be there.  Also, since this was in the formative stages, I was afraid I'd miss something important.  In addition to the frustration of watching people thrashing around, I simply wasted whole weeks when time was of the essence.  Eventually, I had to decline these invitations and trust another manager to fill me in.

Email and Open Door Policy
It's great to have an "open door policy", but sometimes you have to shut the door.  Managers complain than they are constantly interrupted and have to manage by reaction.  Find a way to overcome that.  Schedule meeting time, if you need to, to get your work done in private.   

For emails, on the one hand it's a good idea to respond to emails as quickly as possible, which keeps communication flowing.  On the other hand, emails can be a constant interruption, too.  I am the worst offender on this.  I religiously keep my in-basket clean, and respond to emails as soon as I see them.  But sometimes I should just close the email client if necessary and spend a couple of hours absolutely focused on my work plan or Requirements doc or specs or whatever.

Eliminate Clutter 
There are all kinds of clutter - in your thoughts, in your meetings, in your written communication.  Stay on topic.  Say it simply if at all possible.  As I mentioned earlier, T2M projects come equipped with their own buzz - and if your project is poorly run, the buzz will increase until your developers spend more time buzzing than working toward the goal. 

Take the time to solve problems once, permanently, whenever possible, rather than continually putting band-aids on the same problems as they re-surface.

Remember, confusion is our enemy.  Two things I did that seemed to work well were:

Reduce Scope
The most obvious way of keeping focus, and the smartest thing to do if you can, is simply deliver a smaller product - less features, fewer functions - without sacrificing quality.  Reducing scope is always the first place to look for such tradeoffs - arranged at the beginning of the project (if you wait until the end, you may have already invested hours and effort in designing the jettisoned portion).  

You should partition your product into two clear sets:  (a) core functionality, and (b) everything else.  Thus you will have separate releases.  That's obviously the way to get the core functionality in as quickly as possible.  The other advantage is that a smaller project is always easier to define, develop, and implement.  Take it in chunks.

There is naturally a downside when reducing scope.  Since functionality is decreased, competitive advantage can be lost.  This depends a great deal, of course, on the structure of the product itself.  For some situations, it's easy to identify discrete blocks that should be done first.  In other situations, that's more difficult.  Also, when the schedule is extremely aggressive, "Radically Decreased Scope" (more commonly derided as "temporary cheesy substitute") can be risky.

Avoid new technology.  If at all possible, resist the urge to introduce new technology (including mature technology that's new to you) in this project.  To do so introduces risk via unknowns, plus it adds to the project time.  The only exception would be if the new technology is introduced specifically because the technology itself offers an order of magnitude efficiency.  Doesn't often happen.

Reduce Scope Right at the Beginning
Even knowing that my goal was to reduce scope to the bare necessities, on one project I fell into a trap.  The business user asked for a large amount of work, and wanted me to investigate every piece to explain how it worked, and then give an estimate.  When the estimate turned out to be ten times what was possible, we had to start paring it down.  Eventually we got it down to 1,000 hrs of work and deferred 9,000 for a later phase.  We wound up with what "absolutely has to get done" at the end of the process, and thus kept the scope as tight as possible. 

But at what cost?  During this crucial analysis phase, I (and those I had called upon for help) had spent 90% of my time on work that we weren't going to do for the time-to-market phase!  Every day I spent on that 90% was a wasted day!  When I realized this, I could have kicked myself.  I should have directly asked my business user, who is a reasonable person, right at the beginning to start with what absolutely had to get done - scope that out and see where we stood before thinking about adding other things.

Look for a Quick Strike 
In some situations, where there is a lot of money at stake for every day the project is not in, you might be able to find a temporary arrangement that will allow for a "quick strike."  Get creative.  

I have a great example of a quick strike that almost fell into my lap.  The solution here was just to radically reduce scope; other situations might require more creative solutions.

I was given a project with requirements nearly finished.  There was almost $100k a day at stake.  Essentially it consisted of opening up an existing fee to the rest of the customer population.  The requirements as stated asked for a lot of stuff:  new codes, new downstream processes, a complicated double-pass mechanism to make sure we got everything.  There was a hard due date of January 6, but everybody said we could never make the date.  My first question was, "If there's this much money at stake, why can't we just open up the existing fee, getting the $100k a day ... and then do the rest in a second phase?  So I asked around, and everything fell into place (how often does that happen?).  The project went in on November 25, a month-and-a-half early, and we earned an extra $2M for the company's 4Q P&L.  The Executive Sponsor was so excited he actually jumped up and gave me a high five.  Ok, so we got lucky.  But we got lucky because we were proactively looking for ways to achieve a quick strike. 

Lock it Down
Every developer I talked to named one thing they thought was most critical to their success:  "Give me clear, definite specs that are accurate, correct, and permanent ... and that's what I'll do."  Anything less leads inevitably to stops and starts, reverses, and a lot of wasted time.  The first step is to get really good requirements and high-level design - don't skimp on those (see paradoxes, below).

Handle Scope Creep.  This is easier to say than to do!  The most prevalent type of scope creep is, of course, the "say, while you're in there ..." variety.  These requests always seem to be innocuous and even (from a larger perspective) time-efficient.  But they also distract from the focus of the work.  Once you've established a tight scope, document it and get it signed.  The business users and your staff will inevitably think of things that should be added.  You can't just add them in, in a piecemeal way, otherwise your scope will grow and the schedule will suffer.  

But you don't have to "Just Say No", either.  You can cheerfully accept their ideas and recommendations.  Say, "Good idea!" (if you think it is), and, "I'll put this on my list."  Then gather your list together, and together with the users brutally prioritize them into phases:  (a) must be done now; (b) must be done immediately after first implementation; (c) deferred to later, but will definitely do; (d) wish list. 

The Nancy Reagan Approach?
Speaking of "Just Say No" - some project managers, when given requirements that seem to be excessive, not feasible, or too costly, just say No as loudly as possible.  This is called "push-back."  It's also called, tongue-in-cheek, the "Nancy Reagan Approach."  Traditionally, the business asks for the moon, IT responds by saying everything is too hard, and they compromise somewhere in between.  Maybe this game works in the normal day-to-day environment (although I don't it), it is totally out of place in the T2M quest.

A friend of mine, a highly respected project manager, once told the Executive Sponsor, "We can't do this.  It's just too hard!"  The Sponsor replied, "You tell me how hard it is - and I'll tell you if it's too hard."  Point well taken.

When faced with business requirements that were an order of magnitude more than we could possibly achieve, I told my business sponsor, "I will never refuse to do work you ask for.  But I will never promise to accomplish the work in the required time if I know I can't do it.  That would be lying to you; and you don't want that." 

Work in Parallel
Partition the core functionality release into logical sub-projects or sub-functions, and work them in parallel.  The trick is in using the right logical divisions.  Obviously, you want to reduce mutual dependencies to a minimum.  

Most project management guides will tell you that the interface between the parts must be clearly specified and carefully tested.  But it's not only the interfaces themselves.  In one very large project (1.5 yr effort), the work was divided into silos:  (a) user interface, (b) business logic, and (c) database.  Each silo worked primarily in isolation.  The result:  the UI group created error codes and routines, the business logic group created theirs, and the database group created theirs.  Eventually, each silo needed to process each others' errors, which became cumbersome.

And so, the trade-off for partitioning is the cost and difficulty of integrating the pieces. 

Use Stars
Several studies have indicated that the best programmers are ten times quicker than the worst programmers, and I don't need to belabor this.  In the real world, the best and most experienced developers in the organization can often do the work of 2-5 of the average.  Therefore, when time to market is important, it really pays to use the best and most experienced people you can find.  There are three categories of stardom to consider:  

Get Stars from other projects.  To get Stars, you must take them away from whatever they're currently working on - that is, from other projects.  If they really are Stars, they are almost certainly working on things that really matter to the company.  Thus, this loss can drastically slow down and even derail other important projects.  The cost of doing this is rarely factored into the ROI.  If the Stars come from support groups, the affected groups can be reduced to dangerous levels.  This can also backfire if the Stars suddenly become needed for emergencies, because their absence will cause the project schedule to slide.

Stars don't have to be recognized 'stars' - only the best people for the job.  On one project, the manager passed over some of the heavy-hitters for a guy who was considered just pretty good, and not strong in analysis.  The reason:  the manager had hundreds of programs needing tiny changes, and this guy was the best person he knew for that kind of meticulous work.

Find the right slot for your staff.  John Stockton can't be expected to guard Shaquille O'Neal, but give him the ball and watch him run the team.  One developer I knew was a very poor analyst, but an extremely fast and sure coder ... when given specs.  I slotted him, during the project, to just code to specs - I didn't fight it.  And he saved the day more than once and proved to be a valuable team member.  In the long run, a manager should indeed work with his team to develop them however necessary, but this is not the venue for that.  Position your team to their strengths. 

Listen to Your Stars
If your Stars are indeed stars, you'd better listen to their ideas, complaints, questions, and designs.  If they are Stars by virtue of their business knowledge, you'd better include them in the requirements gathering and high-level design.  They're apt to see things that others don't see.  They'll tell you how a decision impacts business areas you've never even heard of.

Don't put yourself on the critical path.  Use your stars!  A senior project manager once told me "Do coding if you must, but resist the temptation to put yourself on the critical path.  If you do, you'll find you have to choose between coding and managing - either way you lose."

Start Earlier and Dig In
One of my favorite mottoes is "The easiest way to finish earlier is to start earlier."  Even though it seems like a non-sequitur, there is truth in it.  Planning ahead allows us to see possibilities and needs sooner rather than later.  Also - once a need has been determined, we want to compress the decision period as tightly as possible.  The more the decision is drawn out, the further away realistic delivery retreats.  For the business to expect crash-coding to make up for this loss of time is naive.

Many project managers treat their work as a foot-race.  They build momentum and save the sprint for the end.  But this is a bad model.  We don't really want to bring frenzy into the final stages of the project!  But that's where we naturally tend to bear down, like the college student doing an all-nighter for the exam - because the deadline is close and the results are fairly measurable.

But the time to bear down and move the project forward as quickly as possible (within certain constraints) is actually at the beginning of the project.  Every week I save when getting the detailed requirements nailed down is a week of project time I save.  The time savings is almost impossible to measure at this point, since the project is probably not estimated yet, but this is where the project manager should bring his urgency.  He is not only on the critical path at this point, he is the critical path.

Fast Track for Approvals
It is extremely important that the business sponsors do not themselves slow the project.  The project manager needs a business sponsor who is positioned high enough in the organization to make quick and authoritative decisions.  At the same time, paradoxically enough, the business sponsor must be low enough in the organization to be available to the PM and to spend the necessary time considering the issues and sometimes diving into detail.  Thus, the optimum situation is a mid-manager business sponsor for day-to-day activities, closely backed by an Executive Sponsor with clout.

The PM's job is to spell out the issues clearly - and at the right level of detail! - with known impacts, so that the business contact doesn't make decisions in a vacuum.  It is also crucial to know what the sponsor's true goals and objectives are.

Take Out the Drama
A high-stakes T2M project comes with its own sense of drama.  There's plenty of urgency inherently in it.  One of the primary goals of the PM should be to take out as much drama as possible, for drama causes frenzy, and frenzy is the enemy of the project.  There will always be plenty of positive drama left, as the developers realize their work really matters.

Call in Favors
Over time, I've developed some friendships with other programmers.  For one project for which absolutely no one had volunteered and everyone (including me) had been drafted, a developer came to me and asked to work on the project.  He was bored and looking for something to do, and he wanted to work for me because he liked and trusted me.  Recently, I didn't have any staff for my project and resource contention was intense.  I saw two friends going to lunch and asked them if they were swamped.  They said, not at all, so I asked them if they wanted to work on my project.  They said sure, and that was that.  It doesn't hurt to be the kind of manager that developers would want to work with.

Green Light for Early Development
The traditional waterfall systems development methodology doesn't work well for time to market projects in at least one fundamental respect.  In the waterfall methodology, the entire project is fully designed before any of the work has begun.  However, when time to implementation is critical, it makes sense to start development on some components as soon as they are well understood. 

Early development of some components is a bit of a gamble:  you might find out later that these components are not needed, or should not be built as envisioned.  Thus you've worked on the wrong things - and so you've not only wasted hours in general, you've negatively impacted the schedule.  You must be very clear about the quality and judgment of your developers.  The programmer's natural impulse is to "get coding", which can deteriorate into "Code-and-Fix", a notoriously unproductive approach.

The best candidates for early development are low-level routines that you just know you'll be using, certain kinds of reports which can be easily tweaked, and off-to-the-side sub-systems.  Stubs and drivers can be judiciously used to give us a leg up on the construction.

Control - Avoid Dependencies on Other Groups
... or make these groups subordinate to your interests.  Subordinating other groups is very difficult.  On the other hand, avoiding dependencies simply places more burden of work on your team!   Since you can't trust other groups to live up to their goals, you want to put yourself in control so you can live up to yours.  However, this typically means doing the work yourself, thus increasing scope.

Temporary Work-Arounds and Long-Term Goals
You often have the design choice of substituting a temporary work-around, something that will "work for now" in hurry-up mode, to be improved/corrected later.  We did such extra work, 1,000 hours of it, for a large project.  A large chunk of that work was necessary in order to de-couple our efforts from another project which was in trouble.  So we made this dependency a formal "risk" to be avoided; and the solution was to create entire sub-systems of our own.  When that project was indeed delayed (as we had feared), we blissfully went forward.

While temporary work-arounds may be the right thing to do given the time constraints, the result is that the work must be completely re-done later (not just enhanced).  The result is that you simply choose to throw away the work-around hours, and increase total project scope.  

If you write temporary code, you also risk the possibility that the proper work will never get done.  The reason it is called the "proper work" in the first place is presumably that it is more complete, easier to maintain, better for incorporating new features, etc.  Making the cheesy solution the permanent solution is tempting, but rarely works in the long term.

Pick-And-Go
Sometimes you have to choose between products, or approaches, or designs.  If one or more of the alternatives could possibly be a candidate for failure, then you obviously have to make sure you don't pick that one!  But if you have, say, two products which are both sound, and seem to be roughly equal, in a T2M situation you do better if you quickly choose one and move on, rather than spend a lot of time agonizing over relatively small differences.  Sometimes (and only sometimes) "pick-and-go" is the right approach.

Get the Real Date
Is this date the real T2M, drop-dead date?  Is the sponsor negotiating?  Let's say you are given March 1 as your T2M deadline.  You make agonizing trade-offs in order to hit the date - you spend money, reduce scope, write temporary code, etc. - that you wouldn't have had to sacrifice for, say, an April 1 deliverable; and you are successful.  But what if the sponsor truly needed it by April 1, but told you March 1 as a negotiating ploy, because s/he figured you'd be late?  Then you have made foolish sacrifices.

Is the date arbitrary?  Is it just a milestone date that's used to show progress toward a more important future delivery?  You have to know that.  Otherwise, you will make trade-offs possibly impacting the real goal in order to make the milestone.

You Shorten the Target Date
The project manager should set the team's internal target earlier than the deadline.  Since making the deadline is deemed so critical, you should build in contingency weeks at the end of the project, in case system problems arise.  This, in effect, compresses the schedule even more.

There are issues to resolve when maintaining two sets of target dates!  You don't want to lie to your team (making them think your internal target is the commitment date); and you don't want to give the internal target to the sponsors, who will be tempted to make that the commitment date!

Get Testers/Helpers
One excellent way to add additional people is to add "tester/helpers".  Many companies don't have dedicated testing groups, and testers who are also "helpers" can take some of the tedious tasks away from the more experienced developers.  Just make sure they don't get in the way of your main staff.

Another idea comes from the fact that the PM is on the critical path at the beginning of the project.  Arrange for project management and requirements gathering help - at least for the first stages.  For my largest project (11,000 hrs) I actually asked a sub-project manager to partially forsake her own portion and help me for a time as a project administrator.

The Paradoxes of T2M

Interestingly, it is a fact of Time to Market life that certain paradoxical situations prevail:

Here are some details about these.

Extra, Specialized Project Management
Time to Market issues require a great deal of extra thinking and planning in the early stages of the project.  The project manager must make specialized decisions over and above the normal project planning routine.  The PM actually burns hours looking for ways to reduce scope - eliminating some areas of work, substituting work-arounds, etc., which requires additional, careful analysis.  And s/he also needs to consider various staffing scenarios and work with upper management to arrange for special staffing.  And this is all on the critical path!  This has the effect of lengthening the project's scope and hours.

Also, ironically enough, the mere existence of a time to market project creates overhead:  it triggers an astonishing amount of buzz (meta-project discussion) which drains time away from the central effort.

Clear Requirements and Design
This issue is the greatest paradox of T2M projects.  Nearly every developer I talked to said the most important factor to them was to be given specs which were clear, definite, accurate, correct, and permanent.  Having a stable basis was the key to writing and testing code quickly.  The better the requirements and design are, the quicker the developers can reach code complete. 

However, this is by definition a project where time is of the essence.  The ordinary cycle of complete requirements definition, followed by complete design, has to be compromised because of the time constraints.  Certainly, waiting until everything is completely specified at the detail level pushes the project time-line back.  The natural instinct, and almost overwhelming temptation, is to go rapidly through the requirements/design phases, hoping to fill in details later.  And therefore, we give the developers only what we can immediately define.  Their specs are sketchy, and as the project progresses, we discover exceptions, changes, extensions, redefinitions, ... and possibly even show-stoppers.  And the code has to be re-visited time and time again.  That's not the way to get things done quickly.

What is the resolution?  Extreme focus on the requirements on day 1, questioning everything at this point (not later), making everything clear.  "Why?" "Why?" "Why?" uncovers flaws early on.  After high-level design, done with full Star participation, we can partition the project.  This partitioning will delineate those aspects which are fully understood vs. those with open issues.  We can move right into detail design and coding for the parts that are clear, as soon as they are clear.

Flexibility 
The kind of project manager you want handling your critical projects, especially T2M, is one who has little tolerance for ambiguity and confusion.  You want someone who is like a bull-dog - and clarifies, clarifies, clarifies.  The paradox here is that T2M by nature must allow for turn-on-a-dime changes in direction and design.  So the PM has to be flexible.  The resolution would probably involve a PM who hates confusion, but is good at absorbing and resolving it.  The project team must be stamp out confusion, but must also embrace it.

Testing
Regarding the paradox of testing T2M projects, again the temptation is to do only minimal testing:  slam it in, and fix whatever breaks after the fact.  The decision about doing this, of course, depends on what kind of product it is, what missing the date means, how much tolerance the company has for a flawed product, etc.  

A quick story.  We had an impossible date on a very customer-visible project.  Our competitor advertised their version on a huge nationally televised show; their version was obviously faulty, and the combination of high visibility and poor quality was raked over the coals in the trades.  Our project manager said, "Hey - let's not go there.  Even if we're late to market, let's have a product that the world does not mock!"  There's always that angle.

What is the resolution?  There's one things that always works.  Testing is all too often thought of as a separate project phase, usually system testing, that occurs after all the coding is done.  But just as important is the all-too-frequently ignored discipline of rigorous and intelligent unit testing - even sub-unit testing.  Software engineering books (not only the theoretical ones, but the practical ones as well) continually stress the principle of finding and fixing bugs as early as possible.  There is thought to be an order of magnitude difference in fix cost from stage to stage:  if it takes 1 hr to find and fix an error during unit coding, it will take 10+ hrs during integration/system testing, and maybe 100 hrs after product release.  A rigorous code-and-test, code-and-test process, in well-defined increments, is always faster than the alternative.  Maguire stresses the cultural value of "early bug fixes" as a major factor in T2M success.

Perceived Success
Gerald Weinberg tells a classic story about programmer A and B, given equivalent assignments.  I freely paraphrase from memory, making up my own details.  

Programmer A starts coding immediately, and has a "90%" system finished in three days.  He goes through several iterations of testing, never quite getting it right - also makes significant business-rule changes as they are discovered.  He finishes in a month at 250 hours, putting in a lot of overtime; 4,000 lines of code.  It still has a lot of bugs, and the users are not especially happy.

Programmer B stares out the window and writes cryptic notes for the first few days, and it takes him two weeks to produce his first system.  He finishes testing in another week, and turns in his product - 1,000 lines of code, 120 hours, almost no overtime.  His system does everything it's supposed to do.  Users are happy.

You'd think (knowing that the two assignments were equivalent) that B would get promoted and A would be sent to a class or something.  But their manager, judging by appearances only, sees that A worked very hard, continually problem-solved, and apparently put together a system that does four times the system of A.  Boy, was A's system hard!  A is promoted.  B is not.

There is a close parallel in project management.  Project A, which not only comes in late but experiences one problem after another, is often accompanied by long overtime and stressful conditions.  Almost super-human efforts are usually required to get it done at all.  Like programmer A, the appearance is that this team tackled a problem that was supremely difficult and accomplished the objectives only through extreme heroics.

Meanwhile, Project B comes in on time, under budget, and the project team works normal 40 hr weeks.  The PM accomplishes this using principles like the ones outlined above.  Let's say Project B is just as inherently difficult as A - if that's so, then the efficient team deserves kudos.  Instead, Project A - the inefficient team - is awarded and commended for their valiant efforts.  

Why does this occur?  One of the great paradoxes of all project management is that you can actually be penalized (implicitly or explicitly) for running a smooth project.  You run the risk of making it look too easy, like Willie Mays making a basket catch.  You'd think that, like Mays' career, the statistics could be quantified and would speak eloquently for themselves, but that's not easily done.  

Conclusion

Is it Really Time to Market?
For some executives, I'm sure that the "Time to Market" buzzword is used simply to motivate the troops.  S/he thinks that applying pressure on the development team is going to emphasize the fact that this project is really, really important.  "We can't afford to just goof around on this one.  I want you to bear down."

But the result in real-life situations is often the opposite of what was intended.  The exec wanted a good product, done well, delivered in a timely fashion.  Instead, sometimes, we wind up with a mess.

Combination of Losses
Even in the scenario where the project is done with excellence, I must stress that some combination of trade-offs must be made.  And a trade-off always means, in this context, a loss to the company.  Sure, we hit the date, but at what price?  Perhaps we sacrificed product scope or even quality, we derailed other important projects by stealing their stars, we paid lots of money for temporary work-around code, and introduced project risk ... and that was in doing the good things!  Is that what the sponsor really wanted?  

If the schedule is truly crucial, we may choose to make at least some of the tradeoffs described above.  We may decide to go ahead and assume the risks involved.  But at least we should do this with our eyes wide open.

If most of your projects are Time to Market projects, with true deadlines (rather than due dates), you've got a problem.  Or actually, a set of problems. First, you have no way to prioritize and arbitrate between them.  Second, most of your projects are risky projects. 

Assumptions
At the most fundamental leve, there are two competing alternative approaches.  Each is founded upon its own assumptions.

The first approach bears the (mistaken) assumption that team members are essentially lazy and unless pressured will not bear down on the project.  Success is seen as a motivation issue (and one particular kind of motivation at that.)

The second approach bears the the (correct) assumption that best results are achieved through specialized project management techniques and approaches (especially Extreme Focus and clarity), and that these will of necessity involve trade-offs.

I would caution Executive Sponsors to be stingy when designating projects "time to market" - and certainly not create this designation as a motivation ploy - knowing full well that this will introduce a measure of loss to the company via trade-offs.

And I would reiterate that a well-conceived project plan can transform the knee-jerk "hurry-up-and-code" frantic project into a calm and organized effort which is, after all, the best chance you have of delivering a successful project in a reasonable time frame.

Final Thoughts
As I said at the beginning, I believe that there's a great paradox here.  The ideas presented here are demonstrably true, but they also run counter to the normal company culture.  I therefore consider them (though they are not new) to be revolutionary and highly, highly controversial.  If I give this paper to someone placed solidly within the company culture and they pat me on the head and say, "Hey, that's nice; good job", I'll know they haven't even read it.

[1]  I don't intend to reflect negatively on my company (or on myself!) by giving these examples.  Every company has a mix of successful and unsuccessful approaches and projects.  The whole intent is to focus on the things that really work.

Resources

Maguire, Steve.  Debugging the Development Process.  Microsoft Press, 1994.  Also:

McConnell, Steve.  Rapid Development:  Taming Wild Software Schedules.  Microsoft Press, 1996.

Weinberg, Gerald.  The Psychology of Computer Programming.  Dorset, New York.  1970's

Brooks, Frederick Philips.  The Mythical Man-Month.  Addison-Wesley.  1995

 

 

 

 

 

 

 

 

 

 

 

 

 

A