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

So what issues do I typically find?

Dear reader,

It is not difficult to find challenges to work with in most companies, often you think that it is quite normal in small start-up, however even multinational companies can get you flabbergasted looking into the truth below the nice development process charts.

In my opinion the number one issues is always requirements. How do you make sure you have the right requirements or even have them written down somewhere? How do you impose change control of you requirements? How do you priorities requirements? How do you get the right input for the requirements from all important stake holders? I will write a lot about these issues in my coming posts. However, just to give you a preview, here are some of the issues I typically find:

• Requirements in all forms...


• Lack of quality control and good quality code measures (software Metrics)


• Lack of quality control and good quality code measures (software Metrics)


• Lack of 100% working development process or even no process


• Bad architecture


• Poor understanding of project management, project estimation and software complexity


• Lack of good steering for all development projects i.e. no steering committee on the right level of the company, or only obligations and not the right authority for people who drive projects


• Lack of commitment due to poor understanding of people management skills


• Lack of drive and commitment due to poorly connected company goals with individual goals


• Political games


• Line and projects not clearly separated


• Poor visibility or transparency on the status on ongoing development projects


• Lack of good customer support and handling sw bugs

This I s just the short list :-). However if you solve many of the above issues you are on your way to a much better future.
But remember in the end it does NOT help you if you can write fancy process or buy nice tools. The number one thing is to get everyone in you team onboard and actually implement and work according to the new ways of working and that is the most difficult task to achieve IMO.

Over and out for this time…

Step 1. Find out what is actually wrong!

Dear Reader,

If you are new or have had the CTO/VP engineering position for 10 years, it does not matter. You must start from square one. Of course it might be a bit easier if you are new at the job to do this, but do not fall into the trap that you know your organization, especially if you been on the job for sometime. You must get out from you room and start talking to all people in you organization. Start with your own organization and next inline is the organization who orders the products from development (for example product management or product planning). If you have product management or product planning in your organization, you have already found one problem right here :-), more about this in future posts (link).
Why talk to your people yourself? (NOTE: Do not fall into the trap getting a management consultant doing the job for you). Talking to your people yourself will give you at least three things.

1. You will hear and understand the feedback first hand (hence no whispering game, i.e. loss of data) and you can ask follow-up questions directly to fully understand what he/she says.


2. All employees want to be seen even more so if they have been seen by the boss or bosses boss etc. Even better if they also feel they have been heard. Do not underestimate the power of this…
   


3. And most importantly in 99% of the cases, they do not only know what is wrong, they will also know how to fix the problems in most cases

Do not fall into the trap of to many questions. Two simple questions is usually enough (you should of course not forget the “social part” of the meeting as well).

1. What things can we improve?


2. How would you go about to solve these issues?

If you do this simple first step you will have plenty to work with for the coming years…I once meet a manager that did this with more than 150 employees, he was a true inspiration and a fantastic leader.

Next post I will talk about what to do with the stuff you find…

Kind regards
Anders