Breaking Down Large Projects into Manageable Bits

Editor’s note: The following is a guest post by Richard Dancsi. If you’re interested in writing a piece for us, contact gaby@productschool.com

Meet Richard Dancsi

Entrepreneur and independent management consultant Richard Dancsi has worked on a multitude of digital projects – with household names such as Orange, IBM, Vodafone or the UEFA Champions League, and with startups you haven’t (yet) heard of. He helped to get solo founders from zero to one, and helped large companies build and scale: establish workflows and install best practices that put them on the path of sustainable growth.

He’s worked on apps, games, websites, artificial intelligence, and R&D projects. Having built diverse software products across cultures and team structures, Richard now focuses on product rescue, and runs the workshop series Tech Eye.

Richard Dancsi

Making that Project Manageable

There’s a lot of uncertainty at the start of a digital project. As you embark on a new gig, you have to answer a lot of hard questions. How much will this cost to deliver? What does the end result look like? How many people will we need onboard?

Large projects can span months or even years, and some come with a built-in requirement for flexibility. When there’s a chance that the project’s scope changed midway, and the product manager is hard-pressed for a price estimate, how else could they respond other than: “How long is a piece of string?”

Digital teams often have to work within a fixed cost structure, meaning that they give a cost estimate to the client, and the client will pay only that price once the work is delivered. If the product manager misjudged the size of the work at the outset, the team has to eat those costs.

The larger the project, the likelier it is that something unpredictable will come up that alters scope and features. The only thing scarier than a large project is not having a plan to deliver it.

Man standing in front of whiteboard

Bottom up

Once completed a task once, you can generally estimate quite well how long delivering a similar task will take next time. A software developer has built a camera app before will know roughly how long it takes to build a feature to take photos.

Estimating a simple task is easy, and every digital project is essentially just a series of simple tasks. The key to successfully breaking down a large project to manageable pieces is to find the simple tasks, and group them into larger chunks and milestones.

So how many simple tasks does facebook.com take to build?

facebook GIF

The most important thing is to build from the bottom up. You first list all the tasks that need to get done, estimate those, and build the project up from there. We usually do this in three distinct phases:

  1. Write down each and every feature and task that’s required to complete the project
  2. Clean up the list: involve experts and incorporate their insights
  3. Organize the tasks into workable milestones and sub-projects

Step 1: Writing tasks

Use common sense to list out all elements that are required to deliver the product. These can be user stories, product features, individual tasks, pages, app screens, or anything else that helps communicate the idea to someone else. For our purposes, think of a task as something that can be done in a single day.

Always break down tasks into their simplest components, to discover hidden tasks. For example, “Login” is not a simple task, because it comes with many hidden requirements: forgotten password, 2-factor authentication, Facebook login – all these details are important for accurate estimates.

Work space

Use any method to get the list of tasks. You can start by creating a mind map of potential features, or by writing user stories to post-its and sticking those on the wall. Some people would use a blackboard, and others an online Kanban tool.

Continue writing down ideas until there’s nothing left to add. The goal is completeness: in this phase you’ll want to see all the tasks laid out clearly.

Step 2: List cleanup

Once you have a complete and comprehensive list of tasks, you want to make sure that others can understand and use this list.

Every feature and task you wrote down in the previous step has to be clear to someone else to pick up and use. Use more specific verbs for the features: the more specific the verb, the easier it will be for others to understand what to do when they embark on the task.

In this step, we’ll bring in the experts, and make the tasks super clear. This is where you can ask others for help: designers, developers, and people who can perform tasks needed for the project at hand. People who have done those types of tasks before can see if the list makes sense to them. They will point out the areas that need clarification and split or merge tasks where necessary.

To Do List

Step 3: Design the project

The previous steps laid the groundwork for breaking down a large project into smaller steps. In this step, we’ll group the tasks together, create milestones, and design the project timeline. In other words, build the project back up.

It’s a largely creative step, where the product manager has to incorporate all the information about the project and align the goals of product, development, and business stakeholders.

There are a zillion ways to design a project timeline, but here are a few ways to think about this process:

  • You can organize the project into specific phases. Some digital projects have separate phases that require a dedicated expert team as well, for example: design, implementation and testing, phases.
  • Or, organize into a delivery schedule. Sometimes you can find a core product that satisfies all hard requirements. In these scenarios, you can release that product first, and keep adding new features in subsequent delivery milestones.
  • Differentiate based on users. If you can identify specific user groups that can use the product earlier than others, you might be able to release an early product version only for those people. You can build a web-based CRM for back-office booking management, release it, and only start building the booking website when the managers are happy with the system.

Of course, there are many ways to design a project. But the examples above show the importance of working from the bottom up.

When tasks are defined correctly and your estimates are based on clearly defined features, there’s a clarity in the project that is essential to efficient delivery but is otherwise hard to get. With that clarity, you’ll find clear-cut deadlines and a team that can deliver with confidence.

Featured Speaker banner

Enjoyed the article? You may like this too: