How to reach deadlines?

Dear reader,

“I love deadlines. I like the whooshing sound they make as they fly by” (Douglas Adams English humorist & science fiction novelist 1952 - 2001).

I like this quote because it is a bit therapeutic for someone that always chase deadlines and also because it is totally the opposite of my personality, since I hate missing a deadline. However a lot of statistics show the gruesome fact that SW projects most of the time do not get delivered on time and within budget.
Even projects with unlimited founding and the best people fail as an anonymous person commented on the blog on my post form 22nd of February this year: “It is interesting to read the the GAO reports from DoD (www.gao.gov/products/GAO-09-326SP) which goes through of the 50 major weapons programs in USA which has (almost) unlimited founding, the best people and still fail. Many of the reasons identified for these failures apply in smaller scale as well - failure to understand complexity, mistaking new technologies for proven and shear optimism that "it will probably be worked out" without any contingency if the expected miracle does not happen”.

So what should you do to reach deadlines? First of all, imo I think that if you can deliver on time with the right quality and with a maximum overdraft of 10 % over budget you are doing very well for a SW project. Secondly to be able to repeat (only once does not count) your success, you need to have processes, people with the right technical knowledge and tools etc that paves the way for the projects. But setting this a side there are a lot of things that is less tangible and more based on the soft side and they are often even more important. These soft things are what I am going to write about today.

Below you can see my top three things:

• Never give up, but face the brutal facts as early as possible
• Create a team that avoids the "Five Dysfunctions"
• Be flexible on the product scope, not time and quality

Never give up, but face the brutal facts as early as possible:
I have been working as a project manager for many years and a too common thing you hear from project members or sub-project managers are we have failed to deliver this or that and we need to move the deadline since we do not see the possibility to get ready on time. Unfortunately it is also all too common that you get this feedback very late. Many project managers then accepts the situation without looking at all options and gives up the target deadline and starts working hard on new plans and suggesting a new deadline to management or the steering committee. If you have a good project team you should instead sit down with them and look at all your possible options before you “give up”. Be as creative and innovative as you can, you might have to delay this particular activity, but you can almost always find other solutions that speed things up on other parts of the critical chain. If it is really tight you often have to increase the risk level, but that is okay if you can stay on the target (please note: just adding developers seldom has an effect). Imo too many people too easily accept delays, I think this mostly is a mindset issue or maybe they like the whooshing sound :-). By mindset I mean that somehow they have got use to that delays are okay and as long as I can make a new plan everything is fine. If you instead do not accept the delay and try your utmost to find an alternative route most times you will. If you on top of this have a team that avoids the five dysfunctions, hence faces the brutal facts as early as possible instead of waiting to tell you about the problems until it might be too late, you will have even more options to reach the deadline in time. In the very good book: Good to Great you can read more about “Face the brutal fact” (Jim Collins is the author of the book: Good to Great, Built to Last, and How the Mighty Fall).

This post is already too long. I will save the two other parts: "Create a team that avoids the five dysfunctions" and "be flexible on the product scope, not time and quality" for my next blog post.

As a final note, of course there are cases when you have to delay a project, all I am saying is that do not be to quick to accept delay. Because if you are you will create a culture in your department that might think it is okay with the whooshing sound or even start liking it ;-)

Thank you for reading and please give some feedback?

Anders