Timing can be revealing

Time is an often neglected aspect of project planning. Probably because too many people are used to hearing: “We need this yesterday.” When in reality that couldn’t be further from the truth. Perhaps, someone wants this, as of yesterday. But want is not need.

It’s ok to start out with a simple question like when should we start. But never take the answer at face value. Probe further to find out the real drivers of the start date. Even if the date is accurate, knowing why will set you up for success. Chances are you’ll learn something new about the expectations someone has. To find this, ask things like:

  • What happens if we start a day, week or month later?
  • What’s the likelihood that you’ll want to start sooner?
  • What may delay our start?

And not only is the start of a project important. Knowing the constraints around when completion must happen matters even more. Again, questions like:

  • What happens if we finish a day, week or month later?
  • What’s the likelihood that you’ll want to finish sooner?
  • What may delay our finish?

You never know what will come up when you ask these questions. Most of the time I learn nothing new about the start or completion dates but instead learn a great deal about what the objective of the project is. Sometimes things are unintentionally left out, timing is a great way to uncover things. For example, you might find out that an organization will incur a fine if they delay completion. That fine becomes a pivotal piece of information for the impetus of the project. It may be the sole impetus.

You might find out that the project isn’t as much of a priority as people have made it out to be. Asking about possible delays tends to uncover this.

You might discover the project isn’t as important as you thought. I’ve had this happen many times. Another question I like to ask: “What’s the expected duration of the results of the project”. In the case of software, I would frame this as the expected lifespan of the software. Many times I come to find out the system is simply a stop gap. When I know the system is a stop gap, I can pivot to a conversation about the value of the stop gap versus focusing on what’s coming next and whether or not we can simply bypass the stopgap.

Never neglect to probe into the timing constraints of a project.

The constraints that drive timing are often the constraints that drive success.