Perhaps the most misunderstood thing about digital project management is that much of the job revolves around making educated guesses.
We collect user research, client feedback, and team input to estimate scopes and develop timelines, but still, these are predictions. What’s more, it can be difficult to know what level of detail to include at which stage in a project, and how to keep those predictions updated as the project unfolds and builds momentum.
This process resembles the Coastline Paradox, an unsolvable problem cartographers face when mapping an island: As measurements get more detailed, the total length of the coastline increases, approaching infinity. It seems counterintuitive: when looking from 20,000 feet, you can see more of the island, but the distances actually increase as you start measuring every little cape, cove, and stretch of beach.
How Do You Measure the Unmeasurable?
In mathematics, this is called a fractal. In practice, the only way to measure fractals is to compromise by setting a standard for measurement that provides the most meaning while still being feasible to record. In project management, however, the answers may be less obvious: Do you estimate based on FTEs (full-time equivalents (e.g., one person working 40-hour weeks), on hours, or minutes? Do you project timelines in 2-week sprints or in half-day increments? Do you need the same level of granularity for a week-long design update as you do for a year-long software build?
In addressing this issue of fractal geometry, it’s elementary school chemistry that provides a potential solution. When measuring a liquid in a graduated cylinder, one typically reads the closest marking, and then estimates the next increment. For example, if a liquid is about one-third of the way between the 60 and 70 ml markings, one could reasonably estimate it at around 63.33 ml. Likewise, in project management, it’s helpful to have a piece of knowable information with one added level of estimation.
Finding the Boundaries of Your Project
You can use this tool for estimating a potential new project. When building a scope for a website project, review the hours spent building a similar site in the past. Is the new project more complex or less? You can use this tool with your team and put some guide rails on sprint planning. If a ticket is difficult to estimate, present your practitioners with orders of magnitude: Is the ticket likely to take 3 weeks, 3 days, or 3 hours? Clients benefit from these constraints too. Planning a project can get lost in details, so it helps to prompt decision-makers with ballparks around timing, costs, and which stakeholders to include.
This tool of building one level of extrapolation on your known quantities is also helpful once the scope is signed. You can create high-level timing projections months before kickoff simply by looking at your available estimate and dividing the available hours into days or weeks based on a normal allocation and project requirements.
- 35 hours design budget
- 2 scoped rounds of revisions
- Part-time (no more than 6 hours/day)
- Each round of revisions will take half the time of the preceding round
- Client review turnaround decreases with each round
Next, you iterate. Present this proposed timeline to the team and include your assumptions. If timing can stretch further, will it conflict with other projects? If it needs to compress, would it be possible to have multiple practitioners working on it? Share your plan with the client and see which milestones are important to them and which can be more flexible.
Most important, you can layer different levels of detail into the same project plan and update them as you move through the project life cycle. Your current phase may include only daily deliverables, while upcoming phases may have high-level durations based on deliverables or sprints, and distant phases may just be a single rollup task. You can add more detail as you see fit, and leave it collapsed when reviewing with clients until you have validated your projections. This approach works for the waterfall examples shown, but works equally well for agile process: carve out sprints far ahead of time, then add in more detail about what’s included for each of the upcoming reviews and retros.
Mapping New Territory
Note that each phase, especially discovery, should include time to review budgets, confirm alignment with your scope, and pivot as needed. This can mean validating your direction with designers, developers, and clients and rescoping/adjusting timing as you uncover more detail. Shifting conditions and time constraints will always present a challenge in managing digital projects. By extrapolating one level of estimation, layering degrees of detail, and including ongoing opportunities to reevaluate, you can successfully map out your project, rally your team, and build client consensus without getting lost in the weeds.