It’s a well know adage that work expands to fill the time available, and most of us intuitively know this to be true. Because of this, deadlines are a vital tool for any program manager, and all programs must have deadlines. Deadlines give the program manager a way to create focus within the teams which make up the program. In my experience, without firm deadlines a program can drag on and on without ever looking like it’s going to complete.
How to Create a Deadline
If you’re at an early stage in a program then it’s very unlikely you’ll have enough detailed planning done to understand when the program might finish. However, I still like to set deadlines at this point, as early in a program’s lifecycle as possible. I usually try to set the deadline based on a business driven event. Examples of business driven events might include an annual conference where your company typically demonstrates its new products, or a planned service launch date in a particular country.
The good thing about business events when using them to set deadlines for your project teams is that business events are at least very difficult to postpone, and often impossible to postpone. This creates focus within the teams who are attempting to hit the deadline, as they understand why the deadline exists. Obviously, if you’re going to set firm deadlines in this manner then you are accepting that the requirements can change to hit the deadline, as it’s impossible to lock down both schedule and scope.
If you are going to set a firm deadline without a complete understanding of the work involved, then it is important that the whole program team feels that the deadline is achievable but ambitious, as there is no point setting a deadline that you simply know is impossible to meet, and you will never gain the buy in of your team if you take this approach. Additionally, if you are working towards a hard business event driven deadline then the deadline you set the teams should be in advance of this to give your program some contingency.
If your program includes software teams, and they are working in an agile way, then they undertake small chunks of work, each completed quickly, and built to full production quality. However, even these teams can often need deadlines, for example, if you are building a new product based on a new system, then these teams will need to build the system or platform to a sufficient degree that the business feels it has the minimum level of proposition necessary to go to market. With a large and complex new system, this may take many months, so it is important these teams have deadlines too, despite working in an agile way.
An Example of Setting Deadlines
Part 1: In the Beginning
Let’s say that your program began its execution at the start of the year, and that its now mid February. The goal of this program is to build a new type of television. As it’s so early in the program lifecycle, you don’t really have a good feel for how much work is involved, however, you know that your company would like to demonstrate this product at its annual show in October.
In this example I might decide to set a deadline of August 1st for all software and hardware work to be complete. This may to the team seem very aggressive, but that is not necessarily a bad thing as it will really focus their minds as to the urgency of the work, and when they are performing prioritisation on the scope of the work or choosing the technology to use, this deadline will steer them towards more strict prioritisation than would be the case without a deadline.
As mentioned previously, if you’re going to set a deadline in this way, then it’s important to get the buy in and commitment of everyone in the program management team.
Part 2: Management Communication
The program was early in its execution when you created the deadline, so it’s very unlikely the deadline was based on many solid facts about how long the work might take to complete. It is therefore important that you communicate clearly to your management or steering group that this deadline isn’t based on fact, and explain that your reason for giving this deadline was to create focus within the teams.
You should very clearly point out what the alternative course of action might have been. In this case to simply set off working on the TV without any clear deadline. It might have then taken several months to gain a solid understanding of the schedule. Additionally, without a firm deadline that is aggressive, poor prioritisation was very likely to happen within the teams as they tried to cram as many features into the TV as possible.
Explain to your steering group that you don’t yet have confidence for hitting this deadline, but now that a deadline has been set you can start to track against it. It is important to ask the management for their support of this deadline, and ask them to communicate to everyone involved, and at every opportunity, the importance of hitting this deadline.
Part 3: The Deadline is getting Close
As the deadline gets closer you will probably start to observe that some of the teams are unable to hit the deadline. Obviously you should investigate every option available to you to bring these teams back on track, including adding additional resource, and reprioritising the work, etc. However, even after this has been done several times, you may still find that some of the teams can’t hit the deadline, so what should you do?
In our example, if it looked as though all teams could be finished by September 1st, one month after the deadline, then you may think about moving the deadline to September 1st. In my experience this is often the wrong thing to do for several reasons:
- It’s difficult to justify this change of deadline to the teams without losing your credibility. After all, they’ve just spent the last few months working furiously towards the important August 1st deadline, and now, just like that, you’ve gone and moved it.
- Moving the deadline to September 1st would have another negative side effect. Those teams who were tracking close to the August 1st deadline but were going to have to work hard to get there would suddenly breathe a sigh of relief as they now have an additional month to get their work done. This goes back to what I said at the very beginning about work expanding to fill the time available, and all you might end up with by moving the deadline, is a rush to get everything done in these teams at the end of August rather than the end of July.
Because of the above problems, in this situation my preferred approach is to create an interim release, which can happen on September 1st, one month after the August 1st deadline. In my experience, there are several benefits to this approach.
- The teams remain focussed on the August 1st deadline
- Once the August 1st deadline has passed, and many of the teams have hit this deadline and completed their work on time, then resource can redirected to help in areas which are coming late
- Once most teams have hit the August 1st date, the size of the work remaining is much smaller, and therefore the program is running at a much lower overall risk level.
To Conclude
One final point to mention is that it’s very important to keep your management or steering group fully appraised of the situation as it progresses. Make sure you show them which teams are tracking behind the original schedule at regular intervals, and let them know what you’re doing about it. Let them know that you’ll be creating an interim release for September 1st (this shouldn’t be any surprise to them at this point), and keep them focussed on giving the message that August 1st is critical to the success of the product and the business. It’s impossible for me to overstate the importance of proactive, regular communication with the management team.
If this approach to deadline setting is one you use, or you have any comments on this post then let me know. To my knowledge there aren’t any books out there which highlight this approach. This approach is obviously based on my experience of real world program management. I’d be interested to hear from you if you have any experiences of projects or programs running without any firm deadlines, and would like to share your take on the experience.
