Debbie here! I've worked with enough tech companies and startups to know that projects these days have to move fast and be ready to change course on a dime. While PMI (Project Management Institute) style planning is a good fit for many industries, the question "Why bother creating and estimating tasks?" is firmly targeted at those of you who work and thrive in highly changing environments. Why not just plow through the project?
Really? Might there be people (like perhaps your stakeholders) who want to know when your project will be done? Does anyone care if you're on track or not? Are there competing priorities? Is there a deadline? If the answers to these questions are "no," then kill the project. Otherwise, invest a little time to identify, estimate and manage your project tasks at the outset.
Expect your first swag at tasks to be a bit fuzzy at first. You can get clarity by digging into what the tasks are and how long they might take. It's not realistic for anyone to think that you're going to be perfectly accurate. Like anything, you will refine the project as the team delves into the work.
How detailed? How far should you break down the project work? A common rule of thumb is to break the work down to the level at which you can estimate effort. Another answer is, "it depends on your role." As a project manager, I like to get to the level at which I understand dependencies. As a team member, I break it down into more detailed "chunks of work" and create a hierarchy of tasks using an outline. I keep going until I feel like I understand what it will take to do the work.
By the way, I never communicate task level detail to leadership. Leaders usually want milestones, a nice summary of the tasks being managed by the team.
How do you estimate how long tasks will take? You have your tasks, now it's time to estimate how long they will take. I leverage past experience and projects to make my estimates - whether it's in my toolkit of experience or someone else's. I nearly always learn something new when I talk to peers and experts to help me with my estimates.
One common estimating technique is called "t-shirt sizing," borrowed from Agile project management. The idea is to make your best guess at whether the effort is small, medium or large before assigning detailed estimates. I strongly suggest that you define the t-shirt sizes at the outset. For example, Small is 1-2 days worth of effort, Medium is a week and Large is unclear but at least 2 weeks. T-shirt sizing is often done by a small, knowledgeable group.
Finally, don't confuse effort vs. duration. Be clear and consistent. Are your estimates for hands on time (effort) or calendar time (duration across the time available to do the work)? Project management software helps you manage both.
Are you done? NOT YET. Identifying the project tasks and estimating the effort and duration is just the start. However, if you do this well, the rest is easy.
I used a shed project as an example in earlier posts. It applies here as well. Task estimation may not seem like a big deal for building a shed. However, if you live with the potential of rain and snow it may be very important. How long will it take to order the supplies? How long will it take to build the foundation? The structure? Even the smallest of projects has many nuances and dependencies that impact how long it will take.
As my partner in crime, Jenny Warila, and I say, "If you go slowly to go fast, then you will deliver higher quality with less spin in the end." The art is in the level of detail you go into as you break down the work and estimate the effort. Not too refined, but not too high level either!
As they say, LIFE IS A PROJECT. Go practice!
