Continuing along in the theme of my last post, I wanted to share some thoughts on scoping projects and how to avoid some key mistakes that teams make while scoping.

For those unfamiliar with the term, scoping is the process where you estimate how long a project is going to take to complete (or estimate the scope of a project). It generally involves splitting the project into smaller chunks of work / tasks, then estimating how long each task would take to finish in “developer hours”. Sounds like a pretty simple thing to do. So, what are some of the common mistakes and pitfalls?

Well there are the obvious ones:

  • Project Leads do the estimating / Individual Developers don’t participate in scoping.
  • Tasks breakdowns are not granular enough.
  • Time estimates for tasks are overly optimistic.
  • Developers are assumed to have 100% time committed to the project.

All of the above can easily be avoided by following well-known “Agile” practices.

  • Developers do the task breakdown, and the task estimates.
  • Tasks cannot be larger than 2 developer days worth of time. If so, split it up into more granular tasks. This helps you in being comprehensive about the task list, and thinking through your design more thoroughly.
  • Calculate time estimates using a formula that integrates the best-case, worst-case, and most-likely estimates into account. Usually, I find this weighted average formula to be spot on, when there is some thought put into the best/worst/likely estimates –

Estimate = (1xBestEstimate + 2xWorstEstimate + 3xLikely) / 6

  • And then when coming up with a project timeline based on the task estimates, assume developers only get to have 6 development hours/day. It doesn’t mean that they are slacking away the other 2 hours… It’s because immediate-priority stuff always come up.

But, this post is not about those very common mistakes, and their even more common solutions. This post is about my favorite phase of any project – Design – and how it is never properly integrated into the project planning and scoping process.

No time for design:

Or more commonly, not enough time for design.

Every project should have atleast a fourth of its scope allocated for design. Personally, I would even suggest that a third of my time spent on a project should go towards designing it. The more time a team spends designing, the less time they will have to spend in the future implementing - both for the current project, and for future improvements.

Split your tasks:

Everyone knows that design is essential in software development. But, the common mistake project managers do while scoping is bundling design time with implementation tasks. If a task (Task A) requires time to come up with a design first, then split it into two: Task A-1 for Design, and Task A-2 for Implementation, with concrete deliverables for each: A simple email or wiki doc for A-1, and the checked in code for A-2. Doing so will help you get a better understanding about how complex or simple you expect the design to be.

Also, this way, you can move your design tasks to the beginning of the project and have a better estimate on when you expect the overall design for the project to be completed. Which leads us to my next point –

Design early:

Get done with most of your design tasks early in the project. Not necessarily all of it, but most of it. Enough to help you finalize product requirements, and figure out how everything is eventually going to fit back together, and work like you expect your code to. Project managers are generally good at breaking the project into smaller tasks. But what they commonly forget is that you have to eventually put these tasks back together, and designing early helps you figure out whats involved in that.

Designing early also helps product managers get a better sense of what’s feasible; what requirements are must-haves and needs to be implemented for the minimum viable product (MVP); what requirements could be changed/sacrificed; and, get a much better picture of the project’s timeline. It should be obvious by now that you your original task breakdown would have changed substantially. So, you should…

Revisit your scope:

After your initial design phase, you should revisit your original scope estimates and make modifications to it to match with the design you have so far. This is when the Scoping phase is actually complete.

Project managers generally spend an hour in a scoping meeting to come up with a scope. The good ones might spend a day for planning. That only works well for subsequent sprints (We are talking in Agile jargon here) in a project where the design has already been done, and the task breakdown is already a mature list with lots of thought put into it. For the first sprint of the project (or for non Agile projects where we don’t have sprints), Scoping should be lot more than just a meeting. It should be a process that is design-heavy.

Design Along:

Just because there was a design phase doesn’t mean you get to design every single thing at the beginning. There will definitely be design tasks that will be deferred for future sprints, and new requirements get added to a project all the time, that may require some design time. As I stated above… Split the task, design the task, then implement the task. And if you follow scrum, you know you can adjust the scope for your implementation task after you are done with the design task.

Formalize! Scope and Design: Design, then Scope.

Finally, formalize this as part of your Project Management process, and watch your projects succeed. At least when it comes to being transparent about progress, and hitting your timeline dates