Work Breakdown Structure: Planning a Help Desk Migration Task by Task

A work breakdown structure, or WBS, takes a big project and splits it into pieces small enough to estimate, assign and track. For a help desk migration, that means turning “move to the new ticketing system” into 18 or so tasks with an owner and an hour estimate each, so you can see the real size of the job before you promise anyone a date. Do that and the vague phrases disappear. “Set it up” becomes four separate configuration jobs, and “get the team ready” becomes training material, three sessions and a cheat sheet, each with a number beside it. The project stops being a feeling and turns into a list you can argue with.

I used to think a project plan started with dates. It starts with the list. Most support projects slip for the same reason: nobody broke the work down, so the biggest tasks hid inside phrases that sounded small, and the date was promised before anyone knew what it was a date for. The bigger the system, the worse it gets. When Levi Strauss moved its patchwork of country systems onto a single SAP platform, the budget was under $5 million, and the company ended up closing its three US distribution centres for a week and taking a $192.5 million charge in the second quarter of 2008. A help desk migration is a fraction of that size. The failure mode is the same one, scaled down: the work nobody wrote down is the work that bites on cut-over day.

How does a work breakdown structure work?

You start with the finished project at the top, split it into the major deliverables, then split each of those again until you reach tasks one person could own. The lowest level is the work package, and it’s the only level anyone actually works on. Everything above it is just a way of grouping. Give every piece a number as you go (1, then 1.1, 1.2, 1.3 underneath it), because the numbers are what let you sort, total and track the thing in a spreadsheet later. The top of the tree comes from the scope. If you haven’t written down what done means yet, the one-page project charter is the place to start, and the breakdown is how you find out what that charter really costs. Two rules keep it honest.

The 100% rule. The pieces under each heading must add up to all of that heading’s work, and nothing more. If a task isn’t in the structure, it isn’t in the plan, and if it’s in the structure twice, you’ll pay for it twice. Deltek’s guide to the work breakdown structure states it simply: the structure has to include all of the work in the project scope. That’s why the WBS comes straight after the scope is agreed, not before.

The 8 to 80 hour guideline. A work package should take between 8 and 80 hours of effort. Under 8, you’ve broken it too finely and you’ll spend more time tracking than doing. Over 80, it’s still a project in disguise, and you can’t tell whether it’s on track until it’s finished, which is far too late to do anything about it. The guideline isn’t strict. It’s useful for catching the one line in your plan that says “migration, 3 weeks” and nothing else.

What does a breakdown look like for a help desk migration?

Take the project of moving a desk to a new hosted ticketing system. The structure below has six branches and 18 work packages. The hours are illustrative, for a team of about a dozen agents, and every package sits inside the 8 to 80 hour band: the smallest are 8 hours and the largest, the cut-over weekend plus first-week support, is 40.

WBS code	Branch or work package	Hours
1	Plan and requirements	36
1.1	Walk through today’s process with the desk	12
1.2	Write and agree the requirements list	16
1.3	Set success measures and capture a baseline	8
2	Configure the tool	80
2.1	Categories and priorities	16
2.2	Service level timers and escalation rules	24
2.3	Email-to-ticket and customer notifications	16
2.4	Reports and the weekly backlog view	24
3	Move the data	60
3.1	Export and clean open tickets	24
3.2	Test import and check results	20
3.3	Final import and verification	16
4	Prepare the people	56
4.1	Write training material	24
4.2	Run three training sessions	24
4.3	Produce one-page cheat sheets	8
5	Go live	60
5.1	Cut-over plan	12
5.2	Cut-over weekend and first-week support	40
5.3	Rollback criteria and plan	8
6	Close	16
6.1	Post go-live review	8
6.2	Hand over to day-to-day operations	8
	Total, 18 work packages	308

Add the branch totals and you get 36 + 80 + 60 + 56 + 60 + 16 = 308 hours. At a 40-hour week that’s 308 / 40 = 7.7, so about eight person-weeks of effort. Not eight calendar weeks. Hours and elapsed time are different things, and the second depends on how many people can work in parallel and how much of their week they can give you. On a help desk, the honest answer to that is “not much”, because the people who know the current setup best are the same people answering the phones.

Look at the shape as well as the total. Configuration is the biggest branch at 80 hours, which is 80 / 308 = 0.26, or 26% of the whole project. The people branch, at 56 hours, is 18%. That second number is usually the one a first draft gets wrong, because training feels like something you do in an afternoon the week before go-live. Three sessions with material written and tested in advance is 48 hours before anyone has printed a cheat sheet.

How do you put the breakdown in a spreadsheet?

A whiteboard gets you the structure. A spreadsheet keeps it honest once people start changing numbers. Make one workbook with a sheet called WBS. Row 1 holds the headings: WBS code in column A, branch number in column B, the description in column C, the owner in column D and the hours in column E. The 18 work packages go in rows 2 to 19, one per row, in the same order as the table above. So row 2 reads 1.1, 1, “Walk through today’s process”, the owner’s name, 12, and row 19 reads 6.2, 6, “Hand over to day-to-day operations”, the owner, 8. Keep the branch number in its own column even though it’s also the first digit of the code. It makes every formula below simpler.

For the grand total, type =SUM(E2:E19) in E21. SUM adds every hours cell from row 2 to row 19, so 12 + 16 + 8 + 16 and so on down to the last 8, which comes to 308. In E22, =COUNT(E2:E19) counts how many of those cells hold a number, which should be 18. If it says 17, someone has a package with no estimate, and a package with no estimate is a hole in the plan you can’t see in the total.

Branch totals go in a small block to the right. Put the numbers 1 to 6 in G2 to G7 and the branch names beside them in H2 to H7. In I2 type =SUMIF($B$2:$B$19,G2,$E$2:$E$19) and copy it down to I7. SUMIF looks down the branch column (B2 to B19), picks out every row where the branch number matches the one in G2, and adds the hours from column E on just those rows. For branch 2 in I3, that’s rows 5 to 8: 16 + 24 + 16 + 24 = 80. The dollar signs lock the ranges so they don’t slide when you copy the formula down, while G2 changes to G3, G4 and so on. Add I2 to I7 and you should get 308 again. If you don’t, a package has the wrong branch number in column B.

The last column checks the 8 to 80 guideline for you. In F2 type =IF(OR(E2<8,E2>80),"Split or merge","OK") and copy it down to F19. OR asks two questions at once, is the estimate under 8 or over 80, and IF writes “Split or merge” when either answer is yes and “OK” when both are no. On the migration example every row says OK. The day someone types 120 into a package, it flags itself. This all worked in Excel 2007, and it still works unchanged in current Excel and Google Sheets.

How many weeks is 308 hours, really?

This is the conversion that saves the go-live date. Add a second sheet called Calendar. In B1 type =WBS!E21, which pulls the 308 total across from the first sheet. In B2 put the hours per week your team can give the project once the phones are covered. As an illustration, five people giving five hours a week each is 5 x 5 = 25. In B3 type =B1/B2, which gives 308 / 25 = 12.32 weeks. In B4, =ROUNDUP(B3,0) rounds that up to the next whole number, 13, because you can’t go live on the third day of a week that hasn’t got the hours in it.

Most teams that guess at a migration say “a month”. Four weeks at 25 hours is 4 x 25 = 100 hours, and 100 / 308 = 0.32, so “a month” covers about a third of the work. It’s far better to learn that from a spreadsheet in week zero than from the go-live meeting in week four. The other two-thirds doesn’t vanish because the date was announced. It turns into overtime, skipped testing, or a cut-over weekend that runs into Tuesday.

Then look at what can’t run in parallel. The final import (3.3) can’t start until configuration (branch 2) is done, and training material (4.1) is guesswork until the categories and screens exist. Half of the 80 configuration hours sits in two packages: the service level timers and escalation rules at 24 and the reporting at 24. If your desk has never agreed what an escalation trigger is, you’ll find out the hard way that 2.2 takes longer than 24 hours, because the argument about the rules is part of the task. If a work package depends on a decision nobody has made, flag it in column D with the name of the person who has to make it. That’s the critical path, found without any project software at all.

What does the breakdown show you that a plan doesn’t?

First, the number, and the number usually ends the “a month” conversation by itself. Second, the items that rarely appear on a first list. Look at 5.3, the rollback plan, at 8 hours, and 2.4, the reporting, at 24. Those are the two most commonly forgotten, and they’re the two that hurt when you miss them. Without a rollback plan you have no way back if go-live goes badly, and the decision to roll back gets made on a Sunday night by whoever is still awake. Without reporting, you can’t show the project achieved anything, so the baseline you captured in 1.3 was wasted effort.

The same thinking is behind launch readiness: the work you skip is the work that fails on the day. A rollback plan feels pessimistic when you write it. It’s cheaper than any other line on the sheet. Eight hours of planning against a cut-over weekend that would otherwise have no exit is the best trade in the whole structure, and it’s the line most likely to be quietly deleted when someone asks to “trim the plan a bit”. Show me a migration plan with no rollback line and I’ll show you a team that will be improvising one at 2am. The breakdown makes that trade visible, which is the point.

How do you build one without it taking a week?

Do it with the team, standing at a whiteboard, with sticky notes. Write the deliverable at the top and ask “what has to be true for this to be done?” Write each answer on a note, group them into branches and ask the same question of each branch until the notes are small enough to hand to one person. A mind map is a good way to start the brainstorm, and you can turn the branches into the structure afterwards. Two hours is usually enough for a project this size. The agents in the room will name tasks a manager working alone would miss, like the customer notification templates in 2.3 or cleaning the open tickets that have sat untouched for six months.

Then check it against two things. First, scope: does the structure cover everything in your signed-off scope, and is everything in it covered by the scope? Second, your internal and external service level commitments: if the migration puts any promise at risk, such as a dip in coverage during cut-over, it needs a work package of its own. A desk that answers 80% of calls in 20 seconds on a normal Monday won’t do it on cut-over Monday with half the team learning new screens, and somebody needs to own telling customers that before they find out for themselves.

Put an owner and an hour estimate on every package, and have the owner agree with the estimate. A number the owner didn’t choose isn’t an estimate. It’s a deadline. Once you have those, the project plan is mostly a matter of putting the packages in order and deciding who can do them at the same time. The structure stays useful after that too: when the sponsor asks why the date moved, you can point to the row that grew.

What’s the line your last migration plan forgot, rollback, reporting, training, or something else entirely? Tell me in the comments.