My Project Deadline is Approaching and I Am Terrified

The task of delivering software is a challenging job. It is full of hurdles, unknowns and can cause the smartest people to run for their lives.  I am part of a team that will be delivering a major release for sizable product and don't know that I will be able to deliver on time.  I'm scared that this will be the software that is not delivered on time, or even worst, gets delivered but fails to work as intended.  This particular delivery is full of unknowns.  We have some challenges to solve on some things that we have never done before.  We are at a point where we don't know what we don't know and the time started ticking a few months ago.  Will this be the delivery that I am discovered to not be a smart as my bosses think I am?

Delivering software is like that, always running behind or so it seems. You are always solving new problems. The lessons of the last project provide some value but only get you partially there on your new delivery.  The task at hand requires us to research, experiment prototype and throw those prototypes away once we figure out how to do it right.  This process can lead to a lot of anxiety and a lot of stress.  Technology will always require you do new things.  Components and APIs become legacy items.  They have to be replaced with new components and the majority of time these adjustments are anything but seamless.

I have been part of many different teams delivering software for 15 years and have been fortunate to deliver software on time every time.  The majority of deliveries have always seemed impossible at first but in the end they were highly successful.

Throughout these numerous deliveries there are some things that I have learned that I'd like to share and hopefully they will help you help you combat the delivery jitters.

Peel the Onion 

So you don't know what you are getting into.  You don't even know what you don't know.  How can you possibly get good estimates if you have no idea of anything  at this point. One thing I know is that the answer is not going to magically come to you.  Start researching and discovering what you don't know.  This is akin to peeling the onion one layer at a time. As you peel each layer you discover inner layers that eventually make you smarter about the details of your problem.

You can start your research now. You may not know what you don't know but there are some things you do know.  For example, you may know that you are going to be required to produce PDF documents.  You can start looking at available APIs and components.  You can begin tasking some of your team members with prototyping some basic proofs of concept.  You can begin pricing said APIs and components.

Or maybe you don't understand the area of the application that you are modifying. In that case you can start studying that area and dissecting, reverse engineering it so to speak.  This approach will help give you the confidence that you need to work in that area of the application making the modifications that much easier.

The point to drive home here is that you shouldn't wait around for the answer to come to you and you shouldn't let you team members be idle in the planning stages. If they are already on the clock, billing time to the project start tasking them with these things.

Layout The Big Picture

You can layout the big picture by examining your feature set.  You can even start planning the order in which you will accomplish the tasks. You can begin estimating the tasks. Estimating? Shouldn't that have been done prior to the beginning of development?  you ask. In an ideal world, yes. However int he real world there many reasons why the estimates are non-existent or inaccurate.  This could be due to many different reasons.  For example it could have been too early to make the estimates when they were originally made or there were too many unknowns.  Getting estimates will help you plan your project better and will also help you with the next step which is to prioritize the tasks.


Work with your project lead to determine which items are the most important.  Vital items, important and nice to haves.  If you have decent estimates on all your features you can identify date overrun risks.  With this information in hand you can turn to your project manager to help you identify the most import an items to accomplish. It may be OK to not deliver everything that was originally thought up or estimated.  On the other hand you may be in a position to not deliver anytihng short of the estimate.  By prioritizing you can negotiate a strategy with you project manager to acquire additonal resources, such as personnel or tools. By prioritizing, you can ensure that you provide the most value in your product.

Something that has helped me in the past is by breaking down items in three categories:

  • Must Haves - Items that must exist in order for the software to meet it's intended use.
  • Important Items - Items that are significant but the which the user can survive without if push comes to shove.
  • Nice To Haves - These are items that would be really nice to have but are not that important.
By breaking the items into these classifications, you will can be sure to provide the feature set that is most important to the customer.

Pull together as a team

Organize the team so that no one team member is idle.  Lifting 300 lbs is nearly impossible for one person but for a team of six it is Quite doable.  Just like that some tasks that may be impossible for individuals can be quite easy when split up among the team for the heavy lifting.

Keep your manager informed

As you discover any roadblocks or obstacles that will hinder you from completing your tasks, make sure to bring them up to your mananger.  Sometimes your manager may have many other things going on and some of these things may not create a loud enough alert the first time signaled. So make sure to continue bringing them up at every weekly meeting.  This will trigger the manager to make a decision and provide you some help or a strategy to mitigate the associated risks.

Keep Cool

The people that you work with will be there or at least remember you long after the project is delivered.  Always remember that projects come and go much more frequently than the people you come across in your career.  The project is important and should be treated as such but when things get hectic and stressful, remember to keep your cool with your co-workers, team members and customer alike.  Panicking will only lead to more panic and stress.  Panic has 0% percent positive effect on the outcome of the project.

Let off steam

Exercise, do something fun after hours.  Spend time with your family. Don't overwork. Remember that when you deliver this software the clock will begin ticking on the next deadline.  Delivering software is a never ending process.  As soon as the clock stops ticking on you current delivery it starts ticking on the next delivery.  For this reason don't make the mistake of thinking that you can focus 100% of your time to the project and when you are done then you can relax.  That's just not how it works.  Main point to drive home here is to keep a good job-personal life balance.

Don't Run Away

Your project may appear impossible. It may seem that you will not make the deadline.  There may be too many unknowns for a fixed timeline.  Don't make the mistake of running away for this reason alone.  All software deliveries are a challenge.  You have to remember that and that they will always be that way.  There is no reason to run away onto the next job. Chances are that if you run away now you will be running away the rest of your career because all meaningful software deliveries are always a challenge.

Have fun and be confident

As I started this post I may have sounded full of doubt and unsure of my and my team's capabilities. The truth is that it does feel that way but deep down inside I know we have just a good a chance at delivering another successful product as any of the previous times.  For this reason stay confident.  Be able to keep a positive attitude and even some slight sense of humor within your team.  This can go along way in keeping your team members positive and energized.

So if you are just starting your project and it looks like a mountain too high to climb, just remember that this is normal and you can do it.

Please remember to follow me on twitter (@fernandozamoraj) if you would like updates on more posts like this one.


Popular posts from this blog

Simple Example of Using Pipes with C#

10 Methods to Help You Debug Legacy Code