Crunch time is not a project management strategy

George Wright March 30, 2012

Time is ticking...

Time is ticking...

No matter how well planned a software project is why is it that the developers are the ones that always get squeezed?

It’s a fairly common story, a project gets the green light and business cases are generated. The financials are put together, rough estimates and functional specs are agreed upon. User experience (UX) and design are briefed and maybe someone even remembers to get Network Ops involved at the begining. The sales team starts working on a communication plan and launch events for key clients. Project kick off!

Work begins and a stakeholder wants to tweak something or market conditions change. The UX team wants more time to run user workshops or the systems architect gets sick for a few days, or key hardware is delayed due to a distant volcano grounding couriers. Slowly the shape of the project changes, even before the development team starts cutting code. 

Suddenly the business case and project reality part ways.

Senior management still want their product ready, after all that is what the business case promises. Key clients were told launch dates and they have planned accordingly. In the end, the developers get what they need later than estimated but they aren’t allowed to appreciably change their delivery dates.

This “crunch time” phase of the project is never pleasant for any involved but the programmers feel it especially acutely because they are so powerless to control the circumstances. Sadly, crunch time has become the norm and is even being glorified in the game development community.

There have been many techniques that have tried to address this project management conundrum from the traditional manufacturing oriented waterfall approach to “lightweight” methods such as Extreme Programming (XP) and Agile Programming. While there have been some documented successes for lightweight approaches, and I do like them, they still fall short because at the end of the day, in real business, deadlines still loom.

Project management of software is a tough problem and it isn’t made easier by the fact that creating software is effectively the art of making the intangible, tangible. The difficulty is for any decent size software project to look and feel right and do the things it is meant to do and still be within the imaginations of the entire project team.

Lightweight development methodologies such as Agile advocate making as much of the software demonstrable (tangible) as early as possible. This helps draw out misunderstandings and difficulties before too much effort has been expended. The sooner those parts of the system solidify the sooner they are accepted by everyone and the more friction there is to making last minute changes.

The old saying of 'measure twice and cut once' actually works against software development because it creates this false expectation that if we spend more time planning we will spend less time changing our minds. Sometimes the way it works on paper feels wrong once put into software or what appears as mild scope creep actually results in fundamental changes under the hood.  I feel that the modern digital equivalent should be 'prototype twice, go live once'.

Why does crunch time happen regardless of how hard we try to avoid it?

Fundamentally, software creation is experiential and iterative - we need to experience the software to know if it is what we really want. We tend to undervalue getting the foundations of the design right and over value edge case optimizations. We expend a lot of energy trying to deal with the esoteric and interesting “may be needed”. I am as guilty as the next person because I enjoy coding solutions to interesting problems. Scope creep is most evident when a good design enables all these value added software features and we take our eyes off implementing the design as planned to focus on those extras which make our product more unique in the market. Without discipline the “nice to have” gets upgraded to “must have” but the deadline approaches unchanged. 

Sometimes these must have features are forced upon the developers due to market conditions, competing products or an overzealous sales person promising it to a client without consultation. This is totally demoralising as needs to be transparent so that the development team can understand where the changes are coming from and that it is not some whim that devalues their efforts to date.

This isn’t about adding in more contingency time to projects. Work expands to fill the available time and too much breathing room creates a lax environment and results in “we’ll work it out later, we’ve got time” or equally as bad “I’ve got plenty of time to work on this awesome unrequested feature”. 

Developers need to have a voice throughout the entire process. Too many times I’ve seen programmers give rough estimates on pre-wireframed concepts and then be held to the estimates even when the designs are delivered late and no longer resemble the concepts the quote was for. This is a dreadful practice that only creates antagonism in the delivery phase. Changed feature requests should mean new estimates.

Writing software is not an assembly line process, no amount of project management can get around the fact that some days the code just doesn’t flow. Good software-oriented project management should be about protecting the team from spurious changes, politics and sudden priority shifts and creating a space where the developers can write good code with minimum rewrites, on time and under budget.

Why do you think that the development phase gets squashed and why do we never seem to be able to account for it?

This author is on Google+

twitter  Follow IT Pro on Twitter