Crunch in IT project management

 In IT development, the issue of crunch or crunch time is a prevalent issue with many implications. Crunch refers to an extended period of time where software developers work extra hours to finish a project or meet deadlines. This is often a result of many factors, including poor initial planning, insufficient time allocated to the project, changes to requirements or even unforeseen circumstances. The idea of crunching is rooted in the assumption that more time spent on the project would be equivalent to more work getting done. However, studies have found that increasing working hours generally have an overall negative effect on productivity and at best can only boost short-term productivity.

 

Some have proposed agile framework as a solution to the problem, as it make errors and mistakes more apparent early development phase, it involves clients regularly, meaning that it is unlikely for client to be shocked by the results towards the end and request major changes and finally, it allows teams to adjust goals along the way so the workload is more manageable.

However, it has not worked out as such when applied. In fact in some cases teams have found that when using a waterfall development framework, towards the end of the project, there is a intense period of time where employees are expected to work overtime, but during the rest of the time leading up to the last period, the work is usually more spread out and employees do not feel as stressed out, as opposed to in some cases when agile methodology are applied, where teams have to put in extra work towards the end of each sprint, which makes it feel like they are perpetually in crunch mode.

Some would argue that is the case only when the agile framework is applied badly, but perhaps if it is applied badly so often, the framework needs to be improved so it can be applied correctly more easily and more frequently.

Neither agile framework nor waterfall framework is perfect and work well with all projects, instead they have different strengths and weaknesses and are more suitable for different kinds of projects. Companies should not limit themselves to only one kind of project management strategy especially if they have many different kinds of projects, with varying scale, and types of requirements.



Waterfall project management style is a linear project management style where the deliverables at each stage have to be completed before the project can progress to the next phase. This allows for more standardization across the team, workflow is more structured and project requirements are decided early. This is suitable for projects where more precise and straight-forward requirements are needed to meet strict regulations, strong documentation is required, the timeline is fixed, as waterfall produces a more predictable outcome.

However, it is considered the more traditional style of project management, where it is too inflexible and often customers only get to see the end product towards the end of the project. This means that less opportunity for feedback is available and if there are major changes to the market or requirements, it would be difficult for the project to adapt. It is also not suitable for long term projects that continuously change through the years, think for example a social media website.
 

Agile is a more flexible project management style, where the overall task is broken down into smaller parts to be completed iteratively. During each iteration goals are set, before the task is completed and finally feedback is taken for the work done in that period. This generally allows the team more power to decide on the direction of the project and to change it along with the changing circumstances. It also involves more customer input. This is appropriate for projects with dynamic or changing requirements, where perhaps a business direction has been determined but the technical aspect is still open to changes, where it is more experimental and there is no fixed final product in mind yet.

However, there are some drawbacks as well. Sometimes the team finds it hard to get a hold of the clients and cannot progress on, since the scope was not determined from the start.  If order of work is not determined early on, dependencies between team members of teams can cause delays when using a more flexible framework. As requirements are not set early on, it means that it might be difficult to get everyone on the same page.

Large scale projects with strict regulation, requiring strong documentation and precise specification might be more appropriate to use waterfall, for example for Enterprise data system, whereas a more customer oriented product, like a social media for example, where the market reaction to features matter for the next developmental phase would probably be more suited for an agile framework.

So what can be done to improve the crunch problem if agile is not the panacea? Well for one, it is not just about the methodology applied by how it is applied as well. Firstly, it is important that companies do resource planning reasonably, putting in sufficient buffers. Software development tends to be a dynamic work, where there is not a single pace where employees work, as opposed to a job in an assembly line for example. When programming there can be hiccups along the way, unknown errors or unforeseen integration problems that can arise. Taking the employee’s top velocity and expecting them to continuously output the same amount of work is not a good estimate. Secondly, companies can try to build a culture that protects against it. This would involve being willing to negotiate with clients for changes if required, respecting employees time and work-life balance, not placing heavy competition between teams, such that teams are encouraged to push longer hours to “win” or over promise to gain an edge. Lastly, it is to compensate employees in the event that a crunch is required. This can come in the form of extra day-offs during less busy periods, or higher overtime pay. By allowing employees time to relax, it allows them to come back to work more focused and ready to perform.

Generally, crunch has been found to be a problem not just for employees, as it disrupts their work-life balance, and sometimes even affects their health, but also companies, as prolonged crunch periods cause employees productivity and morale to fall. It is important that companies manage their projects, not just to ensure that deadlines are met but also that employees' well-being are taken into account. There is not one size fits all project management style that works best. It is best to tailor the style to the project and employees. In fact employees' feedback should be taken on the project management style, as they are the one working on the project and would feel all the pains, and know where all the bottleneck lies. Different employees and different team dynamics might work best with different styles and that should be taken into account as well. Project management is not just a science of finding the most “evidence-based” methodology but also the art of working with people and a dynamic market. 

References:

Agile vs. waterfall. Pros, Cons, and Key Differences. (2021, August 26). Retrieved December 16, 2022, from https://www.productplan.com/learn/agile-vs-waterfall/ 

Cagle, K. (2022, October 12). The end of agile. Forbes. Retrieved December 16, 2022, from https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/
 

Cannon, R. (2017, September 23). Crunch time - even if you succeed, you fail. Medium. Retrieved December 16, 2022, from https://medium.com/@shinytoyrobots/crunch-time-even-if-you-succeed-you-fail-835af4305bad
 

Chow, T., & Cao, D.-B. (2008). A survey study of critical success factors in Agile Software Projects. Journal of Systems and Software, 81(6), 961–971. https://doi.org/10.1016/j.jss.2007.08.020 

Keith, C. (1970, January 1). Scrum & overtime? Scrum & Overtime? Retrieved December 16, 2022, from https://blog.agilegamedevelopment.com/2008/06/scrum-overtime.html