Tactical Leadership

Top-Down or Bottom-Up

Strategy is top-down planning. Tactics is bottom-up planning. Both are useful and necessary planning techniques, and an iterative process is often needed to align strategic plans with the real tactics available.

Many times I'm approached by a frustrated engineer who was just handed a vague project description, a hypothetical list of engineers, and a highly aggressive delivery date, and asked to produce a detailed schedule and project plan. They're usually bewildered, and sometimes furious. They don't understand how a senior manager can come up with a delivery date before any detailed planning has started, and before the requirements are well defined. What they don't realize is that the high-level plan, with vague requirements, rough cost and target delivery date, is an item in a strategic plan. They've been handed a top-down plan -- a natural process of the flow-down of corporate goals and business unit objectives -- and they've been asked for the bottom-up plan. While the top-down plan lacks details and specifics, it is useful to have a framework for creating the bottom-up detailed plan; the bottom-up plan is then used to adjust the overall product strategy, and may result in changes in strategy.

In one particular case, an engineer had been given vague requirements and sent off to come up with a tactical project plan. She worked with me to flesh out the requirements, tasks, staffing, and schedule. In the process, we discovered that the project was far more complicated than it originally appeared -- there were dependencies on other business units, dependencies on new hardware features, and in order to avoid any chance of silent data corruption the software needed to be very complex. When the cost and schedule was far beyond what the company was willing to pay, we looked at features to drop and ways to bring in the schedule. In the end, the best proposal would simply not meet the strategic plan. She presented her results to upper management, and told them they had to change their strategic plan; they either had to allocate more money, more time, or drop the feature from their strategic plan. They chose to drop the feature. The engineer felt like a failure, but in fact she was successful in her task -- she demonstrated that the strategic plan was not achievable, and with the detailed analysis she had done, she convinced management to change their strategic plans. That's far more valuable than just saying "yes sir" and then a year later failing to deliver the feature.

In another case, I had a senior engineer come to me because he was not given a top-down plan. He was told that a new technology was going to be available from third-party vendors, and he should come up with a plan to deliver the software support. He had to come up with both the strategic plan and the tactical plan, something he had never done before, and he had no idea where to start. He could do all the work himself, but it would take five years; or he could use a large staff and get all the features done quickly. But without a top-down plan, without a strategy, he had no frame of reference.

So we sat down and started to work out the strategic top-down plan:

• Schedule
  When would we want to deliver the product? Turns out the hardware that supports the new technology would be shipping in 18 months, but it was unlikely it would be widely used until 24 months from today. So the strategic delivery date would be in 18 months, with a fallback plan to deliver prototype software in 18 months with a solid product no later than 24 months.
• Requirements
  The things you could do with this new technology were vast. So we decided to triage the requirements into must-haves, nice-to-haves, and non-requirements. Since this new hardware would be replacing existing hardware, the "must have" requirements were to allow customers to transition smoothly from current hardware to new hardware, without any loss of functionality, but with significantly improved performance. The ability to take advantage of new features in the hardware were "nice to haves". And a small subset of features weren't even going to be supported in the hardware next year, so those became non-requirements.
• Cost
  The main cost was going to be staff, and the number of engineers could be small, or large. So I asked this engineer what would be "optimal." There were three key areas that needed development and he could probably do any one of them in 18 months; although, it was unlikely that the project would get three senior engineers. But one of the pieces was big and could be split in two and handled by two junior engineers. So the answer was three or four development engineers for 18 months.

We now had a top-down strategic plan: Three or four engineers would deliver the full set of legacy features plus some new features, and would deliver the product in 18 to 24 months to align with hardware availability. This engineer was actually surprised how our analysis had produced a top-down plan that sounded a lot like the sort of plan his manager usually gave him (which he had always assumed was just made up without any thought at all).

With the top-down plan, the engineer was able to work on the bottom-up plan, defining tasks, assigning tasks to his ficticious engineers, and seeing which requirements could be accomplished in 18 to 24 months. At first, he was unable to get the tactical plan to exactly match the strategic plan, but with the flexibility in the strategic plan, he was able to adjust both plans until they did matched.

This isn't too different from the way we approach projects in our everyday life. Last year I had some work done on my house. I started with a vision, a strategic plan:

• I had a home improvement loan (cash, burning a hole in my pocket).
• I had to replace the siding and so some repairs (must-have requirements), but I also wanted to add a bay window and a back porch (nice-to-have requirements).
• I wanted the work finished before the start of Summer (I didn't want construction waste around the house while children were playing in the yard).

Then I set out to define my tactics. I could do the work myself. That would meet my budget, I wasn't sure I could actually manage lifting a bay window, but I knew I could never finish before Summer (of this year, at least). So my wife quickly eliminated that tactic and had me contact a bunch of contractors, all with good reputations and a long list of references. I sat down with each one and explained my strategic vision, what I wanted (needs plus desires), when I wanted it (I shaved off a few weeks), and about how much I could afford to spend (I gave a low-balled figure, of course). Then each contractor provided a proposal:

• The first contractor could meet price and features, but was booked until the end of September.
• The second contractor proposed vinyl siding over the existing siding, and an aluminum window (which wouldn't match the existing wood windows). The cost was low and the schedule was fantastic, but it didn't really meet my quality requirements.
• The third contractor was a meticulous craftsman. He presented detailed materials lists, estimates, and sketches of what the house would look like when he was done, but his cost estimate was far more than I could afford.
• The fourth contractor was a little high on price, but he was able to get the work done by the end of June, and would use high quality cedar siding and top-of-the-line windows.

Each proposal was valid, and was a sincere attempt to meet my requirements using different tactics; I decided the forth contractor had the tactics that would best achieve my strategy. I felt bad that I had all of these contractors waste time doing estimates and proposals, but I needed the options, especially since none of the proposals met all my constraints. And I had to find a proposal I could live with.

In a large company, the engineering project lead often plays the role of the contractor. Or more specifically, the project lead represents all of the contractors. The engineer will get a strategic plan which is unachievable in totality, so they will come up with their best guess at a detailed plan. Management will tell them the schedule is too far out, come up with another plan. The second plan will meet schedule but cost too much. The third plan will drop too many features. Finally, the project lead will come up with a plan that doesn't meet the original requirements, schedule or costs, and management can either accept it, or change their strategy. It can be a frustrating process for the engineer (just as I'm sure it's frustrating for a contractor to put together a proposal and still be passed over); and it can be an equally frustrating process for management (and the homeowner). But it is the process most people use to synergize their unachievable strategic plans with the cold hard facts of the tactical situation.

---

[If you're interested in a good home improvement contractor in the Boston area, let me know. I have a few references.]

---

Copyright 2006, Robert J. Hueston. All rights reserved.

Posted at 10:46AM Dec 27, 2006 by Robert Hueston in Sun  |  Comments[2]