response crashing project

  (Adam) The term crashing is defined in the book as the process of accelerating a project to finish earlier (Pinto, 2019). This can be done in a couple different ways, including fast tracking, using overtime, adding resources, and/or improving productivity. While you shouldn’t count on crashing a project, there are certainly times when it is going to be necessary. I think the most obvious example of when to crash a project is when something is running behind schedule. Even the best of estimates can’t capture all of the possible common cause variation that could delay a project, so there is a chance that components of your project slip longer than expected. Crashing the project when you are behind could give you the effort needed to catch back up and get back on schedule. Another example of when it might be beneficial to crash a project is when external market forces cause a change to the scenery you were operating in. If there was a disturbance in the market that makes your project more relevant or potentially profitable, you would want to get into the market sooner to take advantage of that. Think if the team behind Skype pulled a massive crash that enabled them to better take care of large telecons, there is a chance we may have never heard about Zoom.

   My closest experience to crashing was closer to the former example. A part of our development effort simulates missile flight utilizing a protocol called DIS using a UDP broadcast or multicast. A separate tool that we used to create DIS missiles for UDP unicast went offline because our license expired, and we were stuck in a tight spot. Thankfully our developers came together and worked as a team to get us the functionality to create unicast links on our other tool. Even though only one developer usually focuses on that area, the team worked together and ensured that we had a tool we could test with.

 

References:

Pinto, J. K. (2019). Project Management: Achieving Competitive Advantage. Pearson.