So you’re just about to start a new project and it’s time to plan. What should a product owner think about when making a plan? Here are some considerations for those starting out
Working hours in the day
Working hours in the day – people often make a plan with the assumption that a day is 7 hours and all you do is divide the effort in a project by 7 and you’ve got the number of days. This is far from the truth, no one has a full 7 hours in a day to work on a problem, more so for engineers. There is time spent working on problems with other engineers, researching problems, standups, code reviews, support for those with less experience, and DevOps to handle. Not to mention toilet breaks, getting cups of coffee and talking about the next new thing. Working on the factor of an engineer being productive on of a development feature for 75% of the day, that’s 5.35 hour day.
Dependencies – good dependency mapping is a must before you start any development, the team must know what order things need to be done in. The project must understand the risk of a task/feature not being fulfilled. There isn’t an easy way to undertake this task it’s a matter of drawing them out and making sure you have them on a critical path. Don’t underestimate the power of Sprint Zero.
Gantt Charts – often overlooked and often oversimplified. A good Gantt chart is hard to come by and producing one is a skill. I use Microsoft Project which comes with quite a big price tag but it’s gold standard of Gantt Charts. Don’t use spreadsheets with coloured blocks - you’ll spend your life faffing with them and it’s just not the right way to do it. Tools other than MS Project are around, for example SmartSheet is less daunting than MS Project and is still a good tool.
Contingency time, let’s face it life isn’t perfect
Process plans assume people know what they are doing and how to do it. If you have an organisation where there is no standard approach to tasks and feedback on a process isn’t shared, you might as well have not planned it at all. I’m not saying ISO 9001 and level of process and quality control (although I do believe in that) but just make sure everyone understands how things are done.
Experience within a team and what happens when engineers need to work together on a problem or one engineer needs to support another.
Understand your team's weakness – let's not shy away from it, we all have them. There is nothing we can do about it (without getting into risk management). Just make sure you understand what they are.