What I Learnt About Project Management

Vaddadi Kartick
Feb 10 · 7 min read
  • Some tasks require a lot of time and may not pay off at the end. Err on the side of saying no to these tasks, because they have a poor ROI. If you were to tell the client or other stakeholders that you spent two months on something and yielded no result, you’re a bad project manager. Instad flag these risks ahead of time so that an informed decision can be made.
  • Having a plan and communicating it makes people think you’re competent. If you have a good plan but don’t communicate it, people may assume that you have no idea what you’re doing.
  • A project manager spends a lot of time communicating, writing Google docs, updating Trello, etc. It’s your primary responsibility as a PM to keep things and people updated. If you re-assigned a task to another person but didn’t update it in Trello (or whatever tool you use), it means you’re not organised properly.
  • Put everything in writing, whether milestones, availability of people, progress updates or anything else. It lets you organise your thoughts and communicate clearly, without confusing the recipient by rambling. A project manager told me that if there was a mis-communication, and you didn’t put it in writing, it’s your fault as a project manager.
  • In any project, you should be clear about the non-goals — what you’re not doing as part of this project.
  • Things take longer than expected. Or, put differently, we always tend to under-estimate. If you don’t know any better, double your estimate.
  • Don’t give an aggressive estimate to a client even if he asks for it. He’ll blame us for it.
  • A plan may be wrong, but planning is still important, since it makes you think.
  • A good plan today is better than a perfect plan tomorrow. Don’t worry that you don’t have all the information needed at the time of making a decision. We rarely do. Instead make the best decision you can with the information available, go ahead with the project, and re-evaluate later.
  • Identify risks as early as possible, communicate them, and try to mitigate them, say by listing out risks and doing an exploratory project to bring clarity to each.
  • A team needs a process in place to run effectively. Process doesn’t sound like fun, but lack of process leads to chaos.
  • Add process only when needed, after not having it has caused a problem, not ahead of time. Process is not like wearing a seatbelt when you get into a car without waiting for an accident.
  • Once in a while, neglect doing something that you consider important, and if nothing goes wrong, you can remove that from the process your team uses, speeding things up. For example, we had pre-commit code reviews, which we skipped doing, and nothing went wrong, so we have a more efficient process now.
  • Project management is a tradeoff between time, scope, quality and cost. Scope is how many features you’ll have. Quality is UX quality and how buggy it is. Time can be calendar time (“Do it as soon as possible”) or person-hours (“I’ve authorised 80 person-hours, so make the most of them”). You can’t have all. A client who’s uncompromising on all aspects is clueless — you need to push back, even if you lose him. Figure out what’s fixed and what we can compromise on (which is different for different projects) and optimise for that. You can’t optimise without knowing the goal, and you can’t optimise for everything.
  • Have a deadline, since it makes you think about how to spend time more efficiently.
  • Everyone should give a daily update. On Slack, not in a stand-up meeting, since the former lets each person write and read it at their convenience, rather than interrupting their work to attend a meeting, or not even starting it because they have to stop soon, anyway.
  • Decouple people and tasks. Minimise the number of times a person has to wait for another, because that hurts productivity. Your job is to free each person to go as fast as he can. For example, if a frontend engineer needs a backend API implemented, and the backend engineer is busy, don’t prevent the frontend engineer from implementing it himself. A project should be like a car race, where each person goes as fast as he can. Not like a group of laborers carrying a heavy object, where everyone has to slow down to match the slowest person.
  • Say yes to people by default, saying no only when needed, not the other way around. A team is not like a battalion of soldiers who can do nothing unless the sergeant orders it. Bad project management dis-empowers people and kills their drive.
  • Some changes are needed when working with a remote person.
  • Identify what’s must-have and what’s nice-to-have, and de-prioritise the latter. Identifying and saying no to the latter creates space to do the former. You don’t want to be in a situation where you implemented a nice-to-have and didn’t have time for a must-have.
  • Clients don’t like this, so one psychological trick is to put them into a later milestone, like milestone 8. It comes across better than saying no. It sounds like saying yes.
  • Given a choice between a task that takes a day and one that takes a week, the latter makes sense only if it has 5x user value. Don’t say yes to the latter without consciously thinking about user value. Err on the side of the one-day task. If it turns out to not be useful, you’ll have wasted a day rather than a week. Or if it turns out to take double the time, you’ll have spent two days rather than two weeks.
  • If a milestone won’t be achieved, instead of postponing the due date, keep the due date and reduce the number of tasks due. This maintains discipline that at least some tasks should be done by the agreed-upon date, as opposed to none. It also gives you a concrete number to improve your planning. If 5 of 10 tasks planned were done, maybe you should double your estimates in the future.
  • Everybody should have a backlog of things to do. If they have to ask you, “What do I do next?” it means you didn’t do a good job. Or if they have to ask you which of their tasks to do.
  • Prioritise tasks by putting them in the order they should be done. Don’t assign arbitrary labels like low/medium/high or P0/P1/P2. They don’t work. They cause disagreements about whether something is a P1 or P2, which is a silly thing to disagree about. It also leaves open the question of which of these four P1 tasks I should do next. Ultimately what you’ll do with prioritisation is decide which order you’ll do them in, so use a tool like Trello that lets you drag and drop tasks into the correct order.
  • Keep milestones as small as possible. If you find two unrelated features in a milestone, break it up into smaller milestones. Err on the side of too many than too few milestones. It’s better to have multiple milestones achieved in a week than to go three weeks without achieving even one. Putting more work in a milestone doesn’t magically get more done.
  • Things can take 3x the estimated time.
  • Work in an agile manner, constantly re-adjusting scope based on time, rather than making an elaborate plan up front.
  • Keep time fixed and adjust scope, not the other way around. That is, ask yourself, “What do I get done in the next week?” not “I need to launch these 7 features, how many weeks or months will it take?”
  • Once a cycle / sprint is committed, don’t change the tasks in it, and give engineers the flexibility to do them as convenient for them. One engineer told me he prefers to do all the analytics tasks at once. Another told me that’s monotonous and he wants to do one analytics task a day.
  • Plan top-down, not bottom-up. That is, start from the high-level goal and identify what needs to be done.
  • Try to eliminate as many tasks as possible. That yields a greater benefit than trying to plan the order in which tasks should be done.
  • Don’t pack the schedule tightly. That makes the whole thing fragile — when one thing goes wrong, as it invariably will, the whole thing will break. Instead, keep things flexible and decoupled. Add buffers at multiple levels. If you have five engineers available for a week, that’s 200 hours. But you’ll have other overheads like meetings, public holidays, sick leave, and so on, so leave 10% of time for them, and count only 180 hours. Then, if you’ve packed in work estimated at 180 hours, it will take longer, and you won’t have met your milestone. So schedule less than 180 hours. Have buffers at multiple stages, and keep things flexible.
  • When working with a new platform or in a new domain like audio processing, first figure out the basics. Get something working end-to-end, which is called a spike or a tracer bullet.
  • Instead of stopping a project with two features half-done, it’s better to complete one and not even start the other.
  • Estimates are guesses, so call them that. Don’t make them commitments.
  • Your job as a project manager is to always keep the client or other stakeholders informed about the progress of the project and your assessment of where things are. It’s not to tell people what they want to hear.
  • At the end of a project, do a post-mortem where everyone contributes their ideas of what worked well and what didn’t. Don’t blame anyone during a post-mortem. The point of a post-mortem is to learn, not to point fingers.
  • Project management isn’t sexy, but it’s valuable — if not done well, it can cause the project to fail. And at a personal level, you can take pride in a project that was planned well and executed well.

Kartick’s Consultancy

A collective information and insights about our consultancy’s learnings and conclusions.

Vaddadi Kartick

Written by

ex-IIT, ex-Google, Startup Founder, Advisor to multiple startups, Now offering my insights to other companies as a consultant: kartick.org

Kartick’s Consultancy

A collective information and insights about our consultancy’s learnings and conclusions.

More From Medium

More on Startup from Kartick’s Consultancy

More on Startup from Kartick’s Consultancy

Futurecam Values

More on Startup from Kartick’s Consultancy

More on Startup from Kartick’s Consultancy

UX Principles I Try To Follow

More on Startup from Kartick’s Consultancy

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade