"We Need This Done in a Hurry!" How to Prepare for a Rushed Project

It’s Time to Knuckle Down with a Plan. 👨‍💻

Every project management book, course, or methodology has beautiful diagrams of the process. First, you set up the pre-planning meeting; then, you type up the project proposal; and then, when everything gets rolling, you look at the hard numbers. But all that goes out the window when we work on urgent projects! There’s no time for twelve meetings before you start—the server’s operating system will reach end-of-life in one month!!

The team has to shift quickly to pick up the pieces, gather the information, and fill in the gaps as they go.

Some tasks are urgent (The site is down! Help now!), but sometimes an entire project can be urgent, too. So how do you handle it?

Project Discovery 👩‍🚒

As a well-oiled development machine, you’ve prepared for this, right!? To some extent, you likely have. But let’s pretend for a moment that you haven’t.

Here are some quick-start steps:

1. If you already have access to the code base, gather a technical lead and engineer manager to start investigating the issue as part of project discovery. This will help highlight the risks and granular details of the urgent request.
2. Notify the account manager or any higher-level manager who will need to know why all of these resources are being spun up and familiarize them with any firefighting that may need to happen.
3. Schedule a meeting with the person requesting the work and prepare them to bring in critical details related to the request.
4. Start documenting the project discovery in a running document that will soon become your scope of work.

It will be important that you meet the client’s level of urgency on their issue, even if you believe it might not be as big of a deal as they think. This will help show that you hear them, are taking the request seriously, and are available to take on the issue.

How to Find What Matters 🔎

Alright! You’ve set the meeting, the team is doing some pre-discovery, and the company is poised to take on this project. Now, it’s time to get some clarity on what the request actually means for the requestor and their users.

Some questions to get the wheels turning:

1. What level of visibility does the impact of this project have? a. Is it impacting users or administrative staff, or will it impact those groups?
2. Is there currently a best and worst-case scenario? a. If the project fails to complete on time, what will happen?
3. Can a temporary solution address this issue while we work in a more planned way to resolve the issue for future scenarios? a. Sometimes, an issue can be handled with a workaround to solve the immediate need to get users back to a semi-working order. Then, the project can slow down and assume more control over future releases.
4. When is our next meeting? a. It will be important to set up the next waypoint for the team while emotions are high. Some issues require daily meetings, and some just require as-needed updates. It depends on the issue. It's best to ask!

In addition to drilling down to what the request needs, establishing what you need early will also be important. After you get the proposed fix ready, the development team will need a clear path to the best route of testing their fix. For that, they’ll need support and documentation from the clients who know the application best. If possible, get the staff users in the meeting as early as possible to highlight what a good “normal” operation looks like to them.

What Does Delivery Look Like? 🏇

Putting the cart before the horse in an urgent project is easy. You’ve spun up all the wheels! However, discussing and documenting the delivery plan will be equally crucial to a successful project closure. What if the fix exists, but the deployment causes an even more significant issue when you push it out? It happens!

By discussing the delivery, you will get ahead of the game on potential risks, plan site outages for users, and keep everyone in the loop regarding _when _to fix them.

It is not uncommon for an urgent fix to be highly siloed in the area where the request occurs. Let’s talk through an example:

The Request 🪲

Please help! A bug on the homepage prevents new users from subscribing to paid plans in our system. They get an error message, and no one can figure out why.

During project discovery, the developers find that this site's payment process is no longer supported and has stopped accepting payments entirely. This is why payments are no longer processed when a subscription is triggered on the website's homepage.

The Scope Plan 🔭

Thanks to the discovery process, a plan can be structured around the urgent need to replace the payment processor and get paid subscriptions back up and running! As a temporary workaround, the development team recommends setting up a basic subscription path through an existing service like Stripe or Paypal, then migrating any subscribers to the final payment solution once the project has been completed. This will allow new users to make a payment and access the site, but there may be more work on the accounting and business side of the client’s company to keep things running smoothly.

The plan sounds okay to the client, and they will give you a thumbs up!

The Delivery 🚚

The team has connected to a new Stripe account, created a new subscription plan to bridge the gap and run a few new test accounts through the system on the staging site to try it out. Everything looks good!

But, in trying to get a fix out the door quickly, the team misses the fact that the site now expects the newly created Stripe subscription plan to allow users to log in! So, by deploying this change, all existing users will be locked out of accessing the site. 😩

It happens. It shouldn’t happen. But sometimes it does! By highlighting the delivery plan as early as possible, talking about risks, and diving into the different areas surrounding the issue, you should be able to explore potential failures like this one.

Cleaning Up Afterwards 🧹

After the dust settles a bit and the immediate issue has been fixed, cleaning up the work you have done to complete the project is still important. A pull request review of the code is still necessary, even if the fix has been verified to be working. This will save you in the long run and has the added benefit of enforcing good practice. Add details to the pull request description to help your future self down the road!

Hold a retrospective! It can be tempting to sweep the project under the rug and move on to the next thing. However, a team retrospective on how the urgent project went can go a long way to improving the company’s process and understanding of these types of projects. You might find that you had more resources allocated than you needed for the project, but the team felt supported and like they had more options in the discovery process on the issue.