6 Things You Could Do When Given An Impossible Project
It’s Monday morning and your manager requests you to take over a time-critical project and it has all the ingredients for a high quality stressful task.
The feature is a tipping point whether the customer remains with the company or not. Multiple higher ups are very concern about it and therefore keeping close tabs regarding the progress with regular updates. In order to implement, the feature requires a few technologies that you have little to no experience with. To complete the whole anxiety package, it needs to be done as quickly as possible.
This has happened numerous times in my career and my usual reaction? Panic!
Once we are done with worrying, let’s move on with taking actions. Here are a few things that you could do when faced with such a situation.
1. Determine the timeline for delivery
It would be easier to plan when we know about the dateline.
Be specific about it. Is the dateline fixed or an estimation. Does the feature need to be deployed to production by then, or just to a staging environment is good enough? Would the full feature have to be completed and ready? Or, could you do it in phases and the dateline is just for the initial phase?
Depending on the amount of time that you have, it would dictate the scope of tasks that you could do. It will decide whether you need to get help, develop a temporary fix (hack) or complete a good one, go with the full feature or trim some of it.
You could be a superstar programmer, but you still have a finite amount of productive hours. Know how much time you have to deliver.
2. Clarify the requirements and definition of done
Everyone has to be in agreement to what it means for the feature to be complete.
There are already many unknowns about this project. Having ambiguity regarding the requirements would just add to the stress. Imagine being half way done with the implementation, only to be told that you understood it wrongly. I would find some table to flip if that happens.
Get all the stakeholders together and agree what exactly you must deliver for the feature to be done. Better yet, write it down, either in your ticket or email, and get everyone to read and verify it.
Measure twice, cut once.
3. List down all the tasks needed to be done
Once you know the timeline, now you need to plan your actions.
Are there many unknowns? Then you need time to investigate and learn. Obviously, you have to implement the feature. How about tests? Do you have to write a full suite of tests or a few unit tests would suffice? Depending on your release process, do you need QA to verify your changes? Does DevOps have to be consulted on your changes? How about documentation? Do you have to prepare something for customer-facing documentations? Could it be done after the release?
Planning out all of these tasks upfront helps you to deliver the project on time with minimal surprises.
4. Figure out your knowledge gaps and fill them in.
When given a task that you are unfamiliar with, it is best to gather as much information before writing any code. Once you have already known the timeline, then you could decide how much of it could be dedicated to research and learning.
Given the time frame, you may decide to spend a few days learning and exploring by yourself. If there is not much time, then you might have to recruit help from your colleagues that have much more experience. It might be a good idea to get help anyway since it can expedite your learning a lot faster.
Once you’ve gained enough skills and knowledge, you would have more confidence in implementing the feature.
5. Front load most of the work
It is a high stake scenario with countless unknowns on your part. If you are lucky, everything goes exactly you’ve planned. More often than not, the unknowns could mess up your delivery schedule.
To give yourself the best chance of success, it is best to complete as much of the task as fast as possible in the beginning, leaving some gap before the dateline. This way, it provides you some wiggle room in case something goes wrong. The extra time could be used to either get assistance or negotiate with the stakeholders.
Worst case, you’ll have extra time to address the problem. Best case, you deliver it sooner than promised.
6. Communicate often
If you have a good manager, s/he might ping you for updates every so often.
In most cases, that might be micromanaging. But, in a high stake scenario, it is good to keep the stakeholders abreast of the situation. Can we deliver on time? If we can’t, why and how much longer do we need? What’s the testing and deployment plan look like? If the project has multiple moving parts going on concurrently, communicating will help synchronize the effort.
Not knowing just increases anxiety. Keeping everyone informed helps to keep the situation under control.