Project management is difficult, especially in the tech/advertising scene where client expectations can completely disregard reality.
You can help your project manager manage your project!
The PM is only a Project Manager from the client’s perspective. To you, he is a Project Mediator. This means it is your responsibility to tell him what you need to make a project succeed, not the other way around.
If you know how to interact with your project manager, you can be truly efficient, making you happy and the client as happy as possible.
Planning
- Not your typing skill but setting the right priorities determines your progress speed. So you always need to know all client expectations and all deadlines. If your PM can give you that information in a clear overview without forwarding client emails, he is a ninja.
- When the wishes of the client drip in gradually, time disappears like money from Paris Hilton’s bank account. This is because you have to re-imagine your priorities and get back up to speed every time you get new info.
- Setting a deadline closer than necessary always has a negative effect on progress. If a closer deadline would make you work harder, you would be a slacker and they shouldn’t have hired you. So the only effect a closer deadline can have is to cause more stress, introducing more mistakes. Note: acknowledging QA and testing time is not the same as setting a deadline too early!
- If the PM forgot to add QA and testing to the required tasks, you know you should add at least 10% but probably more to the total scheduled development time.
- The earlier you get notified when people that you depend on don’t meet their targets, the easier it is to adjust your planning, the less it costs. Unfortunately most people postpone admitting this to the last minute. A PM with failure-prediction skills is worth his weight in gold.
- Replacing another developer with you on a project can mean you have to redo all the work the previous developer did, or at least do a lot of refactoring.
- Switching the PM on a project will cost at least a full day per developer.
Progress
- Every interruption of more than a minute can cost 30 minutes of time to get back into the zone. So if your PM can save all points to discuss for one moment in the day, much more gets done. Also, a PM that can plan meetings beforehand owns the one that drops in unexpectedly.
- Typing an email takes time, reading an email takes time, browsing through a list of new emails to see which are important takes time. And every moment you stop looking at your code and start looking at emails, you need time to get back into the zone. Less email is more better.
- The more different people you need to stay in touch with, the less time there is for development. Every video chat with another team takes you out of the zone and takes a lot of time to get back in. Ideally, you prefer to talk only to direct co-developers and one PM, no-one else. Try to forget this when you are in a bar.
- Communication about technical details can not be done via the PM. So being dependent on another technical party means a communication-heavy project for the developers, which can halve the effective development time. Especially when the others are in a different time zone.
- Every library, plugin or tool made by a third party that you use carries a risk. But when one is still in active development or never tested in a real project, expect it to work like the first time you used chopsticks (see figure). Every time it doesn’t work, doesn’t have a feature that it should, or is not documented correctly, you need to communicate (bonus time) and wait (bonus time).
- Issue trackers eat time, but may be a necessary evil. Issue trackers that clients are on, are hell. Writing polite comments is insanely time consuming.
Making estimates
- A PM can ask you A) What can be done in the available time? Or B) How much time will the tasks cost? Not both.
- Estimates of your tasks can only be made by you. So if your estimates are wrong, everyone’s planning will be incorrect, including that of the client and the client of the client. No pressure..
- Making correct development estimates is an arcane art because it literally involves predicting an uncertain future. At first you will fail miserably, but after every failure you evaluate and you get better. After 10 years, your estimates can be modestly relied on.
- Estimates should always be a range: a minimum time (optimistic happy estimate) and a maximum time (pessimistic everything sucks estimate).
- It is not always possible to explain why you think certain tasks take a certain amount of time or why you group certain things together as a task. Sometimes it’s just a feeling based on experience (see figure).
- After you have estimated all tasks, adding the maximum estimates for all tasks tells you if a deadline can be guaranteed. At the deadline, when tasks are not done, A) the estimates were incorrect or not all tasks were estimated, B) this calculation wasn’t made, or C) the outcome of the calculation was ignored. Try to stay aware of which it was.
- The more requirements are final at the start of a project, the better your estimate will be. That is because for every bit of info that is not final, you have to branch your future prediction, multiplying the total amount of possible timelines.
- The amount of time it takes to do a task is completely unrelated to how much you, the PM or the client wants the task to be done. In reality this is not understood, often resulting in opportunistic estimates.
- The last 20% takes 80% of the time. Here is why: fixing a small issue takes as much time as building a large feature. The small issues in a project look like only 20% of the project, and are always addressed at the end.
- If you find yourself marking up your estimates so you can slack off, it’s time to change jobs. Slacking off makes no-one happy.
Deadlines
- You found out that the tasks will take too much time. Someone says it is unacceptable to skip tasks AND it is unacceptable to extend the deadline. Then you already know that when the deadline has passed A) Tasks will be skipped, or B) The deadline will be extended. Almost never C) Tasks completed faster than expected and everything was finished in time.
- Whenever skipping tasks or extending the deadline, the overall planning changes. As stated before, changing the planning costs time. The later in the project, the more time.
- A PM can tell you A) “you say it’s unrealistic, but you need to get it done no matter what”, or B) “you say it’s unrealistic, but let’s see how far we get”. What actually gets done is the same in both cases, but in the first case the PM made you feel bad.
- A PM tells you “we really need to get this done”, but you are certain that it is unrealistic. You can either say A) “it’s really not going to happen, we need to change the plan”, or B) ”OK”. A will make the PM feel bad now and better later, B will make the PM feel good now and bad later. B is much easier to say, but don’t say it.
- Whenever a team is stressing for a deadline, all usual processes are suspended. 1) Getting processes out of suspension and catching up always costs more time than letting them run, 2) For any process to get suspended a backlog or buffer is needed. Buffers are expensive. Bottom line: stress is expensive. And remember that stress doesn’t get more done. So assuming the estimates were correct, stress was always a planning or scoping mistake.
- The more experienced you are, the more you know that it really, really matters that you stay relaxed and keep your code clean no matter how stressed out the client is, or the PM, or any other person in the project (see figure).
- Setting the right priorities is the only way for a PM to increase the chance of delivering something useful at the deadline. But changing a priority costs time. Setting new priorities every two weeks is OK. When priorities are changed every few days or less, what gets done before the deadline is guaranteed to be suboptimal.
- Adding developers to a late project only makes it later. This statement is called Brooks’s Law and has been proven over and over again. The trick, of course, is detecting that a project is going to be late before it is, in time to change the plan.
Daily development challenges
- Working effectively on a complex problem while others are talking in the room is unlikely. Thank god for headphones! But discussing a complex technical issue with someone else is incompatible with headphones. So: PMs who avoid (disguised) stand up meetings close to working developers are definite money-makers.
- Unfriendly as it sounds, you always try to avoid helping out by temporarily taking over someone else’s development tasks. You can easily spend a day before feeling comfortable with someone else’s code, even if the fix or new feature could be done in 15 minutes.
- When someone else has modified your black box, it is now someone else’s black box.
- When looking for the latest version of assets, designs or information, here is where to look: somewhere on the network disk OR somewhere on the Google drive OR somewhere in a mail comment/attachment OR somewhere in a Hipchat/Slack thread OR somewhere in a Assembla/Jira comment/attachment OR in some commit message OR in some comment in a Google Doc OR in a Whatsapp or SMS message, OR on some USB stick, OR on someone’s Desktop, OR in someone’s head. How beautiful the world would be if finding the latest version would be easy..
- Keeping resource/asset folders clean is just as complex as keeping code clean. At the very least, one person (the PM?) should guard the resource folder structure.
- A build process that takes 5 minutes to complete (like building a Unity app for Android or iOS) doesn’t cost only the time to complete but also the time to get back in the zone. Debugging an app that way is like carrying an old dishwasher up two staircases but having to wait 5 minutes after every three steps.
- Tasks that are not your responsibility but that are executed poorly, i.e. not working, not according to spec or too late, do have a significant impact on your motivation (see figure).
- The perfect PM is a zen guru, all stress coming in from the client dissipates before he communicates with you. He just stoically sets the priorities after asking you for the estimates. The more this is true, the faster the project will be finished.
- If a new feature request comes in after two-thirds of the development timeline without changing the deadline, of course you will try not to let your poor PM down, but you already know that the project will never win a prize.
- The more open tickets are on your name that you can’t start working on because you need to wait for input from others, the less you will get done that day. If your PM chases people enough to prevent that from happening (including you if you didn’t tag the right people and dependencies!), development is fun!
More
Here is a list of articles that align with my experience when it comes to project management in project-based development:
