Program Management - Working with fixed deadlines helps (team) morale

How often do you think it would be nice not to have a deadline? Just do everything at your own pace, with enough time for a coffee chat? No rushing around? No multi-tasking all the time?

But how often will tax returns be submitted, papers handed in, and projects completed, without a deadline? Would you really feel better to have time to work indefinitely on things?

Scientist just published an experiment/paper, titled "Cognitive performance is enhanced if one knows when the task will end", which demonstrates the psychology behind the importance of deadlines - not just for program management, but for us as human beings: Working against fixed deadlines makes us feel better, and leads to less exhaustion - which seems counter-intuitive at first. Nonetheless it is something which I have observed for years when managing programs: Deadlines/milestones in program management are not only important for a program's success, but also for (team) morale and motivation.

The experiment by Maayan Katzir/Aviv Emanuel/Nira Liberman shows that we as people perform better on a cognitive task, especially those that we don't particularly like, when we know that there is an end to them. Their theory is that opportunity cost decrease closer to an end-point, "because foregoing other activities becomes less costly and because knowing when a task would end frees the actor from the need to conserve effort", which in turn reduces mental fatigue/experienced effort.

We feel less tired and exhausted working on these tasks also when we can see that progress is being made. In program management, especially when working towards a product launch, some tasks will be boring and tedious - running repeated tests, putting together all the documentation for releases, change requests, due diligence, or performing quality assurance/control. We can just say we'll complete these tasks eventually which means they may go on almost indefinitely, or put a deadline against it and get it over with.

One of the counter arguments which I have heard repeatedly over the years when I argued not to move milestones/deadlines, was that moving these deadlines will be better for teams, and that teams think I'm too strict when I push for work to be completed.

Yet, aside from all the program management reasons not to move deadlines, there are two psychological aspects which strongly play into this.

1) Based on my experience it creates a very unfavorable culture when milestones become suggestions rather than mandatory delivery dates, when milestones are often moved because they were either unrealistic in the first place or because an organization doesn't foster accountability. In such an environment, teams tend to converge to the smallest common denominator, which is to ignore milestones altogether. In such an environment, nothing will ever get done. For one, working towards milestones by pushing for execution and monitoring progress along the way is one of the most important tools a program manager has - once this is taken away, a program manager becomes administrative at best, powerless at worst. For two, even those employees and team members who feel an intrinsic motivation to complete their tasks will feel discouraged by the lack of urgency of the people around them. Particularly, when working towards a product launch, work will never be "done" 100%, there is always something to improve (as every engineer will agree). But it's the job of program management (or scrum team if you prefer) to find a measure of "good enough" to complete a milestone/release/deliverable, or work will continue indefinitely and the product may get closer to perfection, but will never make it to market. In large programs you also need synchronization or anchor points for when the work from all the different teams is integrated. Moving or softening these integration points, especially closer to the deadline, has detrimental downstream effects on team morale as some teams will have pushed for them really hard just to learn that they have moved (again).

2) As to the other psychological aspect, the experiment described in the paper shows that the treatment group, which did work against a hard deadline and got their progress monitored, not only got the job done, but actually felt better about (completing) their work. This will sound true for all procrastinators among us, who need deadlines to get their act together (yes, I'm one of them).

This paper demonstrates that a lack of urgency, which may seem "easy going" for some, is actually something we humans typically do not like. On the contrary, if the end is in sight, we can push for a final sprint, focus better, prioritize, and mobilize. This is one of the underlying fundamentals SCRUM and other agile methodologies use - breaking down work into smaller increments with more deadlines, not fewer. In larger programs this become more difficult to do as the milestones are further apart. But there is no reason not to create intermediate milestones.

A curious extreme of the second aspect are constant firefighting missions. You may have worked in a company where, instead of working against a plan, there always seem to be "emergencies" which become sudden, yet highly important, deadlines. They bundle all the resources, receive all the attention. However, had there been a more structured behavior up front, which respected milestones and deadlines with proper reporting and sensible decision-making, these emergencies would have never occurred.

This is not to say, that there aren't any scenarios and situations when you need to move a milestone/deadline. But there are ways to minimize the effect described above:

• Moving deadlines should be the absolute exception and last resort, to only take place in circumstances when unexpected risks materialized (e.g. some tests failed which could not be anticipated, external factors like corona virus). It should not happen because the milestone was (obviously) impossible to meet from the start ("set up for failure").
• When realistic deadlines/milestones are not met and need to be moved, it is because a risk could not be mitigated and/or there was not enough buffer with a good enough contingency plan to manage the impact (for example a supplier indicates that they may have difficulties sourcing a certain material which could be baked in as a buffer, mitigated by signing on a second supplier that is lower risk, or by changing specifications if that was an option). This is what risk management is for - it means to have an early warning system and processes in place to resolve issues (e.g. frequent check-ins, transparent reporting, good data/information, a culture that is open to report issues and ask for help/receive help, sound decision-making). If the warning system or issue resolution processes fail, then the underlying issues (e.g. culture, communication, process) need to be resolved. The unmet milestone is a result of something which went wrong along the way.
• By demonstrating that changes to milestones are an absolute exception and that the right people take responsibility for delays, the chain of accountability can remain intact. This will minimize the impact described under 1) and 2) because milestones retain their credibility.
• If an organization has a high appetite for risks and decides to be very aggressive with milestones - which can be a strategy* - then decisions around setting these milestones should be taken transparently with all stakeholders buying into the risks and their potential impacts. When a milestone turns out to be too aggressive, the best strategy is to clearly acknowledge the issues that led to it, accept responsibility for the impact, and show how the costs (time, effort, money,...) will be absorbed. Such a decision should ideally be taken a soon as possible and not put off (miracles are rare) to avoid downstream effects such as wasted efforts by teams (see 1.2).
• Lastly, under-ambitious milestones are also undesirable as they will be under-prioritized which means they won't get the appropriate attention (see 2).

Fixed deadlines are psychologically powerful because we - as humans and as teams - feel better and more motivated when we accomplish something. And accomplishing something is what program management is all about. This makes finding the right balance for milestones and deadlines an art and a science in itself: they need to be realistic and achievable so that they don't need to be moved, without being too lax either.

--------

*Although I would argue it is a highly dangerous strategy as it is not sustainable because too many milestones will not be met and that will lead into the spiral described above.

This article was edited on 3/11/20 to incorporate some answers to questions and feedback I received.