A recipe for (avoiding) failure — Data Science Consulting

Having worked in consulting for a while, I’ve seen a few projects succeed and a lot more fail. I wanted to list down a few points which help avoid some of the more common pitfalls and ensure that the project moves smoothly.

I’ve tried to group them under a few headers — feel free to pick and choose whatever applies to your project.

Stakeholder Management

• Keep things transparent and people informed — both internal and client-side stakeholders. Mistakes and delays happen — but not communicating them to the right people at the right time just amplifies the magnitude of that problem.
• Manage expectations — Do not overcommit and then under-deliver. If you feel that something is taking more time than expected, communicate the reason for the delay to the client and let them know the updated ETA.
• Talk to people with the right level of detail, and know who to approach for what. If you’re talking about Precision/Recall to a business guy, that isn’t going to be helpful.
• Send a end-of-week update mail to everyone — broader client group(inc. leadership if relationship allows) + internal mid/senior mgmt. — helps in maintaining transparency and flag any major off-tracking.
• 1:1 communications should be avoided. Use distribution lists — or even better, use a Teams channel to communicate with your team. It helps siloed conversations, avoiding last minute surprises.

Project Management

• Define clearly the scope of the project. Spend an entire week if you’ve to-but be absolutely sure to have the project as clearly defined and scoped out as possible.
• List down the individual steps/phases, their outcome and ownership, along with deliverables.
• Against each step/phase, mention the success criteria/KPI
• If the project is a major strategic overhaul and involves many moving parts, it is highly recommended to do a project pre-mortem. A pre-mortem basically involves getting all stakeholders into a room and asking them to list down all the possible reasons as to why they think project might fail. Working backwards from this list, we try to form a strategy to mitigate all of these possible causes.
• Specifically for data projects, I’ve seen a lot of cases where the data received from the tech team didn't match what was mentioned by business. Make sure that the scope and other project details are aligned with both the business and the tech teams of your client. And flag ‘MAYDAY’ if it doesn’t align.

Project Execution

• Build an elaborate plan and track your progress with it.
• Have a 15 min scrum call everyday at the start of the day. The agenda for this call will ONLY be to discuss tasks for the day and the ownership, along with help needed and blockers, if any.
• ANY discussion on any task should be a separate conversation, and not part of the scrum call.
• After tasks have been discussed, the JIRA/project mgmt. board should be updated. To avoid work overheads, you can keep the board simple and use the core functionalities — however, it is absolutely necessary to use a board. Excels don’t work for trackers — and while it may seem a simpler idea to execute, its just not worth it in the long run.

While working on any task, always remember pareto’s principle- put in 20% effort to solve 80% of the problem. Don’t focus on getting the perfect deliverable out for the 1st cut — nothing is ever perfect. Get your first cut out as quickly as possible, get it reviewed by peers/leads and then improve based on feedback. Delays happen a lot of times because someone spends too much time in building the first version.

• Use a 3 level QC framework. For each task/deliverable, have a person responsible(task owner) and a person accountable(QC guy). The first round of QC is done by the task owner, preferably using QC checklists. Then it is passed to the person accountable for QC. Once it clears this level, it goes to the team lead for final review and then gets sent to your clients.
• Be a good janitor — Most code/logic problems can be solved via efficient googling, which is an art to be honest. Learn it, and learn it well.
• However, if you feel you’re stuck at something for more than a reasonable amount of time, reach out for help. Most of us will rather answer a stupid question than fix a stupid mistake.
• Meetings take a significant part of your time and hence should be as efficient as possible. Here are a few ground rules for the same.

Join meetings 5 mins before time. “5 minutes early is on time. On time is late. Late is unacceptable.”

Use a good headset/mic — it helps you concentrate on what is being said along with you sounding very clear for other people on the bridge.

Record meetings — With the permission of your clients, especially stakeholder interviews. It helps avoid misunderstandings/miscommunication.

Radio Silence — Be on mute if you’re not speaking. No one wants to hear your 4 year old kid asking for a diaper change.

Track everything — send MOM’s after every call, preferably within 2 hrs. of a meeting so that any miscommunication/misunderstanding is flagged immediately. Use this template as an example.

• OOO discipline — Inform the team in advance if you’re going to take a leave of absence — it helps us plan accordingly and set realistic expectations with clients. Of course, emergencies can happen and they will be handled accordingly.
• For offshore teams, some engagement managers can be a pain to work with. If you feel that the EM isn’t helping you execute the project better, raise a concern with your delivery head/manager/VP to fix this. I’ve seen a lot of projects go haywire because internal EMs were being a hindrance to smooth work.

Engineering Practices

• Automation —if there is even a remote possibility of having to do anything more than once, automate it. Don’t use excel for removing a column, or cleaning dates or for anything which might be repeated.
• Unless of course you are sending some results to a client, in which case excel is almost mandatory. Make sure you prepare the sheet using any scripting language(e.g Python) and then add any formatting that can’t be done in an automated manner.
• Use Version Control — Most consulting people will brush this off as overhead, but a VCS like Git is a life saver. Not only does it help you collaborate in an easier manner, it is the ideal way code should be written. Learn Git here.
• Task Tracking — Track tasks using JIRA or any other project mgmt. tool that your org uses. It helps explain your progress to your stakeholders as well and in keeping your team accountable for their time/effort. Tasks on most boards can be connected to
• Write production-quality code — there are enough articles like this one available on the internet which can guide you with this. Write quality code and commit to Git everyday.

Team work and leadership

The next few points are with respect to working in a team and being a leader. I’ve tried to summarize my experience and my takeaways.

As an IC(Individual Contributor) and team member

• Be professionally competent — while this seems almost like a no-brainer, I’ve often found people lacking this basic requirement. Do you know everything there is to know about the project/tech you’re working on? If no, go do your research. Study as much as you can and make sure you know 100% of all that might be needed for your work.
• As a team member, learn to deal with disagreements in a healthy manner. Have the moral courage to say no if you don’t align with a particular idea. Discuss, get an alignment, and move forward.
• Prioritize and execute — At any point in time, you’re going to be faced with a lot of tasks. Do a basic impact/effort estimate analysis and pick the easy wins first.

• Be proactive — if you’re facing an issue, try fixing it yourself. If you can’t, take it to your lead and mention the approaches you already tried and how you intend to approach it further. Approaching your lead with a blank slate — without any thought given to a problem — doesn’t help.
• KT Sessions — Conduct KT sessions and record them. This helps in onboarding new joiners quickly.
• Learn to take feedback constructively — Your lead or your manager doesn’t hold personal grudges with you. If they point out an area of improvement, talk to them 1:1, list down the actions you’ll do to improve in those areas, and move on.

As a leader

As a leader, in addition to adhering to all the points above, you’ll need to go the extra mile.

• Ownership — As a leader, you’re the ONLY one who will be help accountable for the project. If the project succeeds, it is the credit of the team. If it fails, it’s on you.
• Explaining the why — As a leader, it is important to explain your teammates why they’re supposed to do a particular task. Rather than saying “Run a model because you’ve to”, tell them to “Run a model because the outputs will be used as a input for a particular calculation”
• If people understand why they’re doing something, they will do it well. Conversely, it is also your duty to ask your VP/senior mgmt. why you’re supposed to do something. Only after you believe in the reasons for doing something, you will be able to explain the same to your team members.
• Be decisive — I had the opportunity to work under a couple of indecisive managers and I hated it. In most cases, the decisions you need to take or the choices you need to make will be uncertain. Take decisions given the current situation and circumstances. Do not think too much of improbable events that may render your decision wrong at a later time. Nobody can see too far into the future, and bringing in too many variables just makes you more indecisive.
• In any case, by the rule of averages, 5/10 decisions you take will be right. However, if you are professionally competent(refer second point in “Team” section above), 9/10 will be right. And if you’ve explained your team members the “Why” properly, the remaining decision will be put right by a team mate.

I’ve tried to cover as much breadth as possible. However, if you need any help with any of the points mentioned above, feel free to reach out and ask for help.

Please do let our team @ Decoding Data know your thoughts, questions, disagreements or suggestions in the comment section below.