Tactical LeadershipThe philosophy, art and science of software project leadership |
|
Monday Jan 29, 2007
Old dogs and new tricks The saying goes, "You can't teach an old dog new tricks." And while there is some truth in it, it is also probably one of the most misunderstood maxims. Note that the subject of the maxim is not the dog; the subject is you. "You can't teach..." The saying is not, "Old dogs cannot learn new tricks." The problem isn't with the old dog; it's with you. Old dogs are perfectly capable of learning. A dog learns tricks when it is in the best interest of the dog to learn the trick, when it believes it needs to learn a new trick in order to earn the respect of the owner, when it needs to survive. But after the owner and dog have lived together for years, they know each other. The dog knows that the owner loves and respects it; the dog knows it does not have to learn any new tricks to win approval. Dogs are actually very smart, and lazy. It knows if it just continues to do what it's always been doing, it will still get fed tomorrow. If you bring in a new owner, on the other hand, the dog is no longer complacent in its current situation. It doesn't know if the new owner will accept the dog unless it learns new tricks. The dog is therefore motivated to learn in order to ensure a secure and prosperous future. I recently adopted a seven-year-old dog. The previous owner warned that the dog begged at the table and there was no way to discourage it. So she continued to feed it table scraps while she ate. But once in our home, after a few days of making it clear that begging at our table was not allowed, the dog stopped. It now sits just outside the kitchen door while we eat and waits, knowing that it will be fed as soon as we're all done. It quickly learned the trick: If it waited patiently it would get fed. Most people (and almost all engineers) are smart and lazy, like dogs (the rest of the people are just dump and lazy). If a leader tries to teach a team of engineers a new trick, it can be extremely difficult. I once had a manager who never required status reports. Then one day, he announced that all engineers would have to submit written status reports by 5pm every Friday. We all listened carefully, and laughed on the inside. The first week, everyone submitted status reports. The second week, about half the people submitted status reports. I think only one person filed a report on the third week (and no, it wasn't me). We all knew that the manager was not about to fire anyone for failing to submit a status report. And he didn't. He mentioned the status reports for a couple more weeks, then the matter simply died quietly. We all knew it would. Sun itself is another example. A couple of years ago, the dot-com bubble had burst and Sun was losing money left and right. While Scott McNealy is a terrific leader who grew Sun to be a key player in the Unix server market, it took a new leader to teach this old dog new tricks. If a team is going to learn new tricks, that is, adopt significant new processes, first the leader must change. The change may be physical (replace the person who is the leader) or metaphysical (the leader changes himself). It can be extremely difficult, sometimes impossible, for a person to change himself, hence the saying: You can't teach an old dog new tricks. Posted at 10:00AM Jan 29, 2007 by Robert Hueston in Sun | Comments[1]
Wednesday Jan 24, 2007
When Good Enough Is Good Enough I have a broken, shattered vase on my desk. It's an eye-sore. And a lesson. Years ago, I had a small ash tree growing up through a fence in my yard. It was one of the few trees in my yard, and I was reluctant to cut it down, but I realized either the tree or the fence had to go. I wanted to preserve a bit of my tree by turning (on a lathe) one section into a vase that could sit on my mantle. Turning "Green wood" (newly cut wood that is still green and wet inside) is different from store-bought kiln-dried wood. The wood is turned on the lathe and shaped with chisels and gouges as usual. But after being shaped, the wood continues to dry, and in the process, it twists and contorts into unusual shapes. But of course you have no idea what your work will look like until months later when the wood has fully dried. Instead of a vase that looks machine-made, it often looks like it has melted slightly, taking on a Dali-esque appearance. I saved a nine-inch section of my tree, and turned it into a very nice vase. My wife thought it looked beautiful and put it on the mantle (and believe me, she doesn't allow just anything on her mantle). But from my unique vantage point in my chair, when the sun shone through the skylight at just the right angle, I could see a flaw. There was a spot where my gouge must have dug in a little too deep and left a tiny, almost undetectable groove near the foot of the vase. It drove me crazy. After a few days on the mantle I could take no more. I took the vase back out to my shop, and chucked it up on the lathe again. But when I turned on the lathe, I realized even just a few days on the mantle had caused the vase to dry and change shape. It was no longer uniformly round, and as a result, it was no longer well balanced on the lathe. As the vase began to spin, it started to wobble, and the lathe began to vibrate. The vase flew off the lathe, whacked my face shield pretty hard, then landed on the cement floor and shattered. I turned a piece of a lovely shade tree into a beautiful vase. But I wasn't happy with a beautiful vase; I wanted a perfect vase, and my own desire for perfection left me with a shattered piece of trash. I keep that vase on my desk to remind myself to be satisfied with beauty, because when you change something, one possible outcome is disaster. The vase is, of course, a metaphor for my work in software engineering. Often, software engineers fall in love with their code, and although they have produced a beautiful product -- a product that meets all the requirements -- they still like to tweak and optimize it. I'm guilty in this area myself. While investigating an unrelated bug report, I saw an awkward piece of code I had written months earlier. As part of my bug fix, I also rewrote this section of code to be more elegant, more streamlined, more perfect. In the process, I introduced a bug at a boundary condition. Whenever a software engineer touches a piece of working code, there is always a non-zero probability that a new defect will be introduced. Sometimes we have to accept that good enough is good enough. Posted at 09:00AM Jan 24, 2007 by Robert Hueston in Sun |
Tuesday Jan 23, 2007
Five things you don't care about me I hate this meme, but I've been tagged by Josh Simons, so here goes... Five things you don't know about me (and probably don't care):
Posted at 11:58AM Jan 23, 2007 by Robert Hueston in Sun |
Thursday Jan 18, 2007
Be Careful What You Measure, It Might Improve There's a saying: That which is measured improves; that which is ignored degrades. But be careful what you measure, because it just might improve. Collecting and analyzing metrics is not something to be undertaken without the proper preparation. When you apply metrics to any activity, the metric may "improve" at the expense of other activities; the net effect might be negative. A long time ago, I was on a large software team developing a new telecommunications product. The project was supposed to be to port an existing code base to a new hardware platform and OS. The differences in the hardware and OS changes were greatly underestimated, and the result was a huge number of bugs. Management was concerned that (A) product quality was very low, with a high bug count, (B) testing was finding new bugs too slowly, and (C) development was fixing bugs too slowly. So they decided to employ metrics. They decided to measure:
At first glance, this seems like a reasonable approach -- it encouraged testers to find lots of bugs, and developers to fix lots of bugs, and it also encouraged them to do it quickly so the product would ship and bonuses would be paid. The result, however, was a disaster. Testers began filing bug reports by the truckload. Every combination and permutation of conditions resulted in a new bug report: The wrong ring tone is used when connected to a BRI interface. The wrong ring tone is used when connected to a Tri-BRI interface. The wrong ring tone is used when connected to a PRI interface. The ring tone had nothing to do with the network interface; it was one software bug, but it was reported as three separate bug reports, thus boosting the individual tester's metrics. Developers were no less shameful. They would seek out the bugs that were quick-and-easy to fix in order to drive up their metrics. Critical, high-priority bugs that would take a long time to diagnose and debug were avoided like The Plague. Also, the quality of code changes dropped, not just because of haste, but if a developer fixed one bug and introduced two others, then the tester would get to file two more bug reports, and the developer could fix two more bugs, driving up everyone's metrics. I honestly believe no one was intentionally introducing new bugs, but the metrics discouraged developers from testing for regression. In the end, the metrics improved -- the rate of bug reports being filed went up, and the rate of bug fixes increased. But the goal was not achieved; overall, the quality of the product actually decreased. After a few weeks, management realized what was happening. They decided to measure the total number of open bugs, instead of maintaining metrics on a per-person basis. When designing a system of metrics (and it is a design process), one has to consider the goal, and identify the measurable criteria directly related to that goal. In this example, the goal was to improve product quality quickly. Unfortunately, the selected metrics were only second-order criteria and were not directly related to the goal. The metrics improved while the goal slipped away. In other words, what you measure will improve, so be careful what you measure. Posted at 10:00AM Jan 18, 2007 by Robert Hueston in Sun | Comments[1]
Wednesday Jan 17, 2007
Anticipate the Unanticipated The key to quality project planning is planning for the worst, and the worst of the worst is the unexpected. How can one anticipate the unanticipated? Software engineering as a discipline has existed for maybe 20 or 30 years. Even electrical engineering is a young 130 years old. By comparison, man has been making war for over 12,000 years, and the science of military planning has a rich history that we can learn from. War, being little more than organized chaos, mandates planning for the unexpected. Battlefield ReservesMilitary planning anticipates the unanticipated using reserves. When a division (approximately 10,000 soldiers organized into three ground brigades) enters the battlefield, it will normally advance with two brigades, and hold one brigade in the rear, just a couple of hours behind the main action, as a tactical reserve. The reserve brigade is available to exploit an unexpected vulnerability in the enemy's line, or to support a forward brigade if it meets unexpected resistance. Similarly, when a brigade is exhausted from battle, the reserve brigade can move forward and take up the offensive. On a larger scale, an army corps may engage the enemy with three or four forward divisions, and hold one division in the rear as a strategic reserve, ready to move when a forward division needs support. Moving a division of 10,000 men is no easy task, and it may take days to bring the reserve division fully into the battle. As a result, strategic reserve is no substitute for well planned tactical reserve at the division level. This same approach can be employed effectively in software engineering projects. Tactical ReserveIn an engineering project, tactical reserve takes the form of staffing reserve, feature reserve, and schedule reserve.Staffing reserve is when in the planning phase you load your engineers below 100%. I generally figure an engineer will spend 20% of his time doing non-development activities: attending meetings, doing overhead tasks, sick time and vacation (note that 12 paid holidays and three weeks of vacation is already 10% lost time). Even so, I try to load my engineers at 70%: 20% for overhead plus an extra 10% in reserve. There is additional staffing reserve -- the other 128 hours a week that the engineer is not normally scheduled to work (OK, all 128 hours are not available, but for short periods of crisis, an engineer who normally works 40 hours a week can easily provide an addition 50% to 100%). At the start of a project, developers may find they can spend 80% or more of their time on planned tasks, and so they get ahead of schedule. Then a problem arises, and the project leader needs to pull one engineer off his tasks to address the problem. Because the engineer was already on the project, there is very little ramp-up time, and the engineer is able to make good progress on the problem very quickly, while making little progress on his planned tasks. But since he was already slightly ahead of schedule, the overall impact is minimal, and if necessary, a little overtime might get the entire project back on schedule.
Schedule reserve is the project's ability to slip schedule without slipping the release date. That might sound contradictory, but it isn't. As an example, consider a new software feature going into Solaris to support new hardware which will be available in June. The base plan may be to release the feature in a Solaris Update release due out in June. But the testing and release process for a Solaris Update is on the order of three months, so the software would need to be complete by March. On the other hand, the feature could be released as a patch to Solaris; patches cost more to release, but only take a few weeks to test and release, and can be further expedited (at additional cost) to release in a matter of days. The base plan would be to complete the software by March and release with a Solaris Update, but the schedule reserve allows completion to slip until May, or even June, and still release on time (albeit, with added cost).
Strategic ReserveStrategic reserve is normally factored into the strategic planning. At a business unit level, the project portfolio may include must-have and nice-to-have projects; and the project schedules may include schedule reserve (for example, we want to release a new feature a year before company XYZ, but it's OK if that lead slips to six months). When one project runs into problems, management can take people from a different project (one with lower priority, or one with more schedule reserve) and apply them to the problem area. Of course, moving a person from one project to another does require a ramp-up time; the person moving may spend days reading project requirements and design documents, and figuring out where they fit into the project. Due to the cost of moving strategic reserves, it is imperative that every project have some degree of tactical reserve. I've seen both sides of strategic reserves in motion. I've been on projects where things go so wrong that more staff is needed, sometimes causing another project to implode. I've also been on projects where management reassigned one or more key engineers to another project. That can be an emotionally frustrating position, but one has to keep in mind that these dicisions are being made at a strategic level, and management must do what is best for the business, even if it means dismantling your project. OutroAn engineer leading his first project once said he wished he could be more like me and not worry so much. That's humorous, because I'm the biggest worrywart around. But I channel my anxiety-induced energy into planning, and in a solid plan I find comfort. I mostly worry about the unexpected, so once I plan for the unexpected, I know I have nothing to worry about. Recommended reading:
Posted at 10:00AM Jan 17, 2007 by Robert Hueston in Sun |
Tuesday Jan 16, 2007
Everything I needed to know about project planning I learned from my little league coach When I was kid, I loved baseball. I was good at batting, but I hated being in the field. I could catch the ball as well as anyone, but once I had the ball, I hesitated, especially when there were already men on base. Should I throw to second and hold the base runners? Should I throw to third and try to get the runner out? And while I hesitated, the runners kept running and the problem kept changing. In the end, I would often compromise and throw the ball half way between second and third -- no man's land -- and the runners would just keep running. My failing was in my fielding strategy: Whenever the batter approached the plate, I would close my eyes and pray that they bunted. If the ball was never hit to left field, I wouldn't have a problem. Sadly, this strategy rarely worked. After years of sub-par performance in the field, my coach pulled me aside and gave me some advice that has stuck with me through today: Before the pitch is thrown, decide what you're going to do if the ball is hit to you. What will you do if you catch a fly? What will you do if it reaches you on a hop? What will you do if it's hit over your head and rolls to the fence? This was brilliant advice! While I would still stick with my main strategy -- pray for a bunt -- I could add a new dimension: thinking ahead, and baseball gives you lots of time to think. While the batter was picking out his bat, tapping the dirt out of his cleats, and adjusting his, uh, stance, instead of counting the number of dandelions in left field, I could be thinking about what I should do if the batter did not bunt. Why didn't my coach tell me this years earlier! Fast forward 30 years... Today, I often see software project plans that assume the project will be fully staffed on day-one, the hardware will arrive exactly on time with no serious bugs, all external dependencies will be met with perfect quality, and no one on the team will ever get sick, quit, or take a vacation day. The project leader lists those assumptions in the project plan, saying, "If all of the assumptions are met, this project will be successful." The assumptions are really risks that they're not planning to deal with and they're just hoping will go away. Basically, they're planning to fail; praying for a bunt. It's easy to plan for the best. The key to quality project planning is planning for the worst, contingency planning, planning for the case where the ball gets hit to you, or over your head. And maybe you don't want the ball, but sooner or later it will be hit your way. I've never worked on a project where everything went as hoped, so good planning is all about dealing with things that could go wrong. Just like in baseball, the absolute worst time to deal with a crisis is during the crisis. There's just too much pressure when the ball gets hit to you to decide where to throw it. And as you stand there, trying to decide what to do, the problem is changing, time is passing, and things are continuously getting worse. If you try to make the decision in the heat of crisis, you're likely to throw the ball into no man's land. Instead, you need to plan for crisis before the crisis happens. Even before starting the project, ask yourself, for example, what could you do if the hardware gets delayed? Can you continue to develop the software using a simulator or using a different hardware platform? Are there tasks you could move around to minimize schedule impact? Are there features that can be dropped in order to shorten the back-end schedule? In the end, it may be impossible to deliver the software less than X months after the hardware is available, and even that information is critical in the project planning phase. Every assumption is a risk, and every risk should have a contingency plan. It's even possible to plan for the unexpected (that will be blog entry for another day). And when you're in the middle of the project, and a crisis breaks out, you can calmly and confidently tell people that everything is going according to plan. Then just do what your plan said you would do. Posted at 10:00AM Jan 16, 2007 by Robert Hueston in Sun |
Tuesday Jan 09, 2007
Breaking The Fourth Wall The term "fourth wall" is used in performance art to describe the invisible barrier between the actors and the audience. On occasion, a performance will "break the fourth wall" by having an actor address the audience directly. While there are many examples in classical plays, my own vivid memory of one example is of the Burns & Allen Show on TV, when George Burns would turn directly to the camera and talk to the audience, one-on-one, about what was transpiring on the show. There actually was no audience on the set, just a camera, but Burns broke the fourth wall just by acknowledging that an audience eventually would be watching the show. As product development engineers, we often hide behind the fourth wall that separates us from our customers, the end-users of our product. We work on products, oblivious to the fact that they eventually will be interacting with our customers. We sometimes design products for ourselves instead of our customers, or ignore annoying little "features" that might drive customers crazy hoping maybe no one would notice, or design individual products without much consideration how a customer will assemble them into a system. In effect, we act on a soundstage in front of a camera, oblivious to the audience behind the fourth wall that will eventually view our performance. Last year I had a rare opportunity to meet with a large customer. I got to break the fourth wall. This customer owned hundreds of our products, from desktop machines up to multi-million dollar high-end servers. Along with a couple of senior engineers from the other product families, we were to present our low-end, mid-range and high-end product roadmaps. While I went into the meeting with excitement and pride, I crawled out of there feeling like a wounded puppy. And I would go back in a second. In the meeting, the first thing the customer mentioned was connectors. Connectors? We wanted to talk about processor architectures, memory capacity, and IO options. Who cares about connectors? Well, the customer cared. On our current high-end products, the serial console connector is an DIN connector, similar to most keyboard or mouse connectors. They found that if the cable is bumped or tugged, the DIN connector could fall out, requiring physical access to the datacenter to re-insert the cable. And very few individuals were allowed physical access to the datacenter. "Why couldn't you use a captive connector, like an RJ11 or DB9?" they asked. I had no answer. The next issue they raised was the command line interface for managing our products. Each product family had different commands. And when two product families happened to have the same command, the options and arguments were often different. "We have to train our employees on three different command sets," they explained, showing a "cheat sheet" they issued to all their system administrators showing how to do the most common tasks on each product line. "Why can't you have one set of commands for all your products?" Again, I had no answer. We had created a great command line interface for our product line, with exactly the features and options our product needed. The engineers working on the other product lines did the same thing for their products. The honest answer to both of the questions is simple: We failed to break the fourth wall before we shipped the product. The customer knew the answer; they were just trying to make a point and get us to realize it ourselves. Aside from the tongue lashing, the customer did praise our products: we did a great job engineering our products, but we could do better. And the customer expressed how happy they were that we development engineers were coming to visit them -- they were glad to see the fourth wall being broken and hoped that our encounter would have a lasting impression. It did. In development, we need to break the fourth wall -- the invisible barrier that separates the developers from the customers. We need to see how customers use our products, understand their issues and concerns, and internalize their pain. And nothing helps internalize pain than feeling it first-hand. It's not enough to read articles, or listen to stories second or third hand. I learned a lot from that customer visit; the people who listen and read my story might only learn a small fraction of it. We need to get all of our developers out in the field, meeting with customers directly, accompanying our Service Engineers on customer calls, shadowing our Tech Support Engineers in our Call Centers, and talking to our Field Engineers (who in many ways are our customers as well). When we break the fourth wall, both our products and our customers will benefit. Posted at 12:16PM Jan 09, 2007 by Robert Hueston in Sun |
Monday Jan 08, 2007
YARPUI How often have I heard a project leader say, "I'm not responsible for the current situation"? It's the moral equivalent of a three-year-old's, "I didn't do it!". To which the official parental response is, "I don't care. Clean it up anyway!" There's a key difference between being responsible for a problem, and being the cause of the problem. A long time ago I learned an acronym that has followed me to this day:
OK, it's a bit of a forced acronym, but it makes the point. No matter how we got into the current situation, no matter who caused it, no one is responsible for helping us, except ourselves. We own the responsibility of our own lives, and extending that to the workplace, we project leads are responsible for our projects, regardless of outside forces. I used to have a sign over my desk that just read "YARPUI," to remind myself of that everyday. I'm not talking about always falling on one's sword -- the hollow "I take full responsibility" sort of statements that are usually followed by excuses. Those are acts of contrition, with all the sincerity of a person who says, "I'm sorry" when someone else bumps into them. Usually the person claiming full responsibility is not about to take responsibility; they are often about to resign, which is the antithesis of responsibility. A person who is responsible takes control of the situation, even when they are not the cause of the disaster. They say, "To hell with how we got here. Let's move forward." No finger pointing. No excuses. No whining. Just action. It can be difficult to deal with bad situations that are not your doing, that are out of your control. I had a young engineering project leader come to my office once, infuriated because one of the critical engineers on her project was pulled off to work on something else. "This isn't my fault!" she insisted. "No," I told her, "but you are resposible," and I introduced her to YARPUI. She needed to re-examine the plan and come up with options: How would this loss impact the delivery schedule? Who else could potentially join the team to backfill? Could features be dropped to save the schedule? And in the end, there was no value in trying to blame anyone for the situation; a simple statement like, "Due to staffing changes, we are replanning" would suffice. In history, an excellent example is George Washington, the Hero of the Monongahela. After the disaster of Fort Necessity in 1754, Col. Washington's Virginia regiment was disbanded and he returned to civilian life. A year later, British General Braddock hired Washington as an aide. In 1755, during the Battle of the Wilderness at the Monongahela River, General Braddock was mortally wounded and the British officers and troops scattered in disarray, easy targets for the French and Indian warriors. Washington took responsibility for the situation. Even though he held no position in the British Army chain of command, he gave orders to the British offices, and rode up and down the lines restoring order and achieving an orderly retreat. Washington wasn't the cause of the situation -- he wasn't even an officer in the British Army -- but he took responsibility and placed his life on the line to extricate himself and his fellow soldiers from the situation. At this point, when anyone who has worked with me for the any length of time is faced with a problem caused by someone or something else, they might stomp into my office, but as soon as I say, "YARPUI", they know that they're not going to find a sympathetic ear. They know they need to get right back to work, take responsibility for the situation, and plan around whatever disaster just happened. At least that's better than listening to another boring story about the Hero of the Monongahela. Quote of the day: "The secret of success is sincerity. Once you can fake that you've got it made." -- Jean Giraudoux. Posted at 03:17PM Jan 08, 2007 by Robert Hueston in Sun |
Thursday Jan 04, 2007
Deciding not to decide is not deciding One of the most important aspects of being a leader is making decisions. Decision making is the tiller of a project; it sets the course and helps maintain forward motion. Good decision making is the cornerstone of good leadership. Four Facts About DecisionsOver the last couple of decades I've learned a few things about decision making:
From the above facts, one can draw the following piece of advice:
Good, Bad and Sub-optimal DecisionsYou'll notice in the above that I use the term "sub-optimal" to describe a decision, instead of "bad." A sub-optimal deision is a decision which is made based on the available information and appears at the time to be the best decision, but once the future is revealed it turns out not to be the best decision. The only way to make an optimal decision with certainty is to have perfect knowledge in advance, which is practically impossible, and typically means there isn't really a decision to make (e.g., Should I get round wheels on my car, or square ones? I can confidently make an optimal decision because there really isn't much of a decision to be made). Most decisions are based on partial knowledge, and while one can take steps to maximize the probability that they will make an optimal decision, the optimality of the decision cannot be known until the future, and sometimes, it can never be known. A bad decision is one which is made without sufficient dilligence, or is made despite indications that it is not the best choice. There are several traps that a decision maker can fall into that lead to bad decisions. [See "The Hidden Traps in Decision Making," John S. Hammond, et. al., Harvard Business Review.] Those traps include:
An ExampleThe four facts of decisions can be demonstrated with a single example from my recent past. I had a small team of engineers working on a software design, and they were stuck deciding between several approaches. After one week, they needed more time. After two weeks, I knew they needed help. I set up a meeting, and we discussed the options. We created a pros/cons table, also called a "consequence table," on the whiteboard. I like to use the first column for the criteria used to judge the options, such as ability to meet requirements, code size (cost to implement), code complexity (cost to test and maintain), performance, and so forth. The other columns are for the various options, and the cells show how well the option performs compared to the criteria. [For a more complete description of the process, see "Even Swaps: A Rational Method for Making Trade-Offs" by John S. Hammond, et. al., Harvard Business Review, March 1988.] We filled out the consequence table and eliminated all but two options which were balanced very closely, options A and B. Nothing we could do made either option stand out as a winner. At the end of the session I looked at the whiteboard and picked option A. I could make that decision easily because:
With a decision made, the team got to work on the detailed design. After a couple of weeks, one engineer came back with a problem: Option A turned out to be far more complex than they had initially thought -- we didn't have perfect knowledge during the consequence table analysis. We had a new decision to make: Stay with option A or change to option B. We did the analysis, and the consequence of staying with option A, even with the effort already expended on option A, would still be more costly than switching to option B. So we decided to change the design. In just a few days, the design had been reworked to use option B. Note that the time it took to change from option A to option B was small. It had cost us weeks of time trying to decide on an approach, and in the end it only took a few days to switch from one option to the other when we had more knowledge. In addition, I still maintain that the original decision was a "good" decision; it was made analytically, with the knowledge available at the time. I also believe the second decision -- to change options -- was also a good decision since it too was based on the available knowledge at the time. Rules To Decide ByWhen making decisions, we should follow a simple set of rules:
Posted at 04:20PM Jan 04, 2007 by Robert Hueston in Sun | Comments[2]
Wednesday Dec 27, 2006
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:
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:
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:
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.] Posted at 10:46AM Dec 27, 2006 by Robert Hueston in Sun | Comments[2]
Tuesday Dec 26, 2006
GOST In The Machine The terms "goal," "objective," "strategy" and "tactic" are often confused and mis-used. I wanted to write a couble of short entries on the GOST terms, and clarify their use. As they say, an ounce of example is worth a pound of advice, so I'll be using examples primarily from the War Between the States.
GoalA "goal" is an endpoint, a future. In war, it might seem obvious that the goal is to win the war. But a goal of "winning" is meaningless, and itself can lead to defeat (I believe many wars have been lost because people were too busy trying to "win" and lost sight of the goal of winning). One must define what winning means in order to define a goal. In the Civil War, for example, the goal of the Union was very different from the goal of the Confederates. The Union's goal was to quash rebellion in the South and force the Southern states to rejoin the union. The Confederates' goal was to defend their secession, to repulse Northern aggression. Both camps had a goal, and marshalled their forces to achieve the goal. The military on both sides could use the stated goal to organize their objectives, strategies and tactics around achieving the goal. An organization's "goal" is often communicated through a mission statement. Some people feel mission statements are pointless -- propoganda, cheerleading. Often they are right, but done correctly, they can also be a powerful tool. One organization's mission statement was "Deliver wow products that elate customers." Sounds catchy, but it's about as useful as having a military goal of "win the war." It is vague and unmeasurable. The mission statement cannot be used to judge the objectives of the organization; it cannot be used as a decision making tool; and the organization cannot know when they have achieved the goal. Could you imagine product managers rating their products, and caneling all "neat" and "cool" products and only spend their effort on the "wow" ones? Or canceling a project because it will only "delight" customers but it won't "elate" them? In constrast, one small aerospace company had a boring-sounding mission statement which I believe to be one of the best I've heard. It went something like: Be the number one or two supplier of aircraft engine sensors and engine status indication systems. It told the company:
Not very catchy, but it did create a frame of reference for directors to review their product development plans and portfolios and make serious decisions. It also provided measurable criteria to know when the goal was achieved.
ObjectiveAn objective is a means by which you attain a goal; it's a step that must be completed in order to achieve the goal. Using the Civil War analogy, the North had a number of objectives in order to achieve their goal. One objective was called the Anaconda Plan: Close the Southern ports to prevent the sale and export of argicultural products to Europe, and the importatation of industrial products and weapons. Of course, England was a key trader with the South, and a second objective of the North was to avoid going to war with England -- war with England would not help achieve the goal of reunification. So the original Northern objective could probably be better stated as: Block Southern ports without risking a war with European powers. With that, an admiral could understand the objective and devise strategies to achieve it. Several strategies that support this objective include:
and so forth. The objective also ruled out the strategy of invading Cuba, a primary port in Southern trade routes -- doing so would have helped blockade the South, but would have led to conflicts with Europe, and could not have been defended by the Proclamation of Blockade. Knowing the objective, one can come up with a set of strategies, and judge if the strategies actually support the objective. Businesses also have objectives to meet their goals. Selling into a specific market or market segment might be an objective. And if you have a well-defined goal, it should be clear which markets to attack. Without a goal (or with a poorly conceived goal), it becomes much more difficult to decide where to apply your resources. Some effort may be spent on fruitless products; other opportunities may be missed. In some cases, a poor goal at the corporate level can lead to conflicting objectives within business units -- one business unit decides to sell a product that competes with another business unit, canibalizing margins. A clear and measurable goal, supported by a set of clear and measurable objectives make it possible to create a set of strategies and tactics to be successful. Without goals and objectives, an organization is just groping in the dark for a purpose.
Strategy and TacticsStrategy is the top-down planning needed to achieve an objective. Tactics are the bottom-up planning to achieve a strategy. More on that in my next entry. Posted at 12:22PM Dec 26, 2006 by Robert Hueston in Sun |
Friday Dec 22, 2006
Plagues, Peoples and Process Change Evolution involves mutation combined with natural selection to decide whether the change was successful and should be continued, or not and should die off. In the book "Plagues and Peoples," William H. McNeill makes the case that societies of humans can evolve, like organisism but at a faster rate. Societies can change (mutate), and if the change is successful, it gets integrated into the society. For example, with a climate change that brings cooler weather, a mammal would require many generations to evolve more hair and a thicker layer of fat as methods to defend against the cold. But as early human communities moved northward from Africa into Europe, they quickly evolved methods to keep warm -- their society mutated, and when the change was beneficial, it was kept and the society prospered. As a result, societies in northern areas that built shelters, wore animal hides, and started eating different foods thrived and dominated societies that could not evolve fast enough. Other societal evolutions are more subtle. Most people in the West have an apparently innate fear of rats, but little or no fear of other rodents such as squirrels. The fear of rats is probably rooted in the fourteenth century Bubonic Plague pandemic, with the belief that black rats carried the disease. It would have taken centuries to develop an immunity to Plague; however, Western Society evolved an abject fear of rats, which caused people to avoid rats moreso than other rodents, and may have helped reduce the spread of the disease. Today in the US, the risk of dying from Plague is extremely low, but like the human appendix, the vestigial fear of rats continues long after its applicability has ceased. An organization or project team is a human society, and evolves like an organism. And just as every organism reacts differently to external stimuli, so does every organization react differently to change. Process change requires a sort of evolution within a team. If the change is handled poorly, it will be rejected by the team and fail, and the team may evolve a vestigial fear of the process, or of process change in general. One difference between natural evolution and organizational evolution is that natural evolution involves random mutations; organizations can think and can therefore make intentional changes. There are many methodologies for implementing change. I actually think the process is quite obvious once you treat the team with respect. I've boiled the process down into the following simple steps: think, ask, envision, implement and observe:
The above steps are a cycle -- after observing a change, one may need to go back and think some more. And it is always acceptable to move backward through the process. For example, one may think there is a way to improve a process, but after asking the process owners, it is clear that a change is not appropriate and you need to go back and think some more. And always keep in mind that process change is evolutionary. If the change is successful it should be continued, if not, it should be allowed to die off and replaced by a different process. Quote of the day: "Rules are intended to provide a thinking man with a frame of reference." -- Karl Von Clausewitz Posted at 11:41AM Dec 22, 2006 by Robert Hueston in Sun | Comments[2]
Thursday Dec 21, 2006
Process Is The Hobgoblin Of Little Minds Everyone follows a process in everything they do. But many people follow processes without every realizing. I once worked with a very talented analog design Engineer, Hal, who could look at a problem and immediately tell you the best solution. He couldn't tell you how he came up with the solution; but he always had the right answer. I suspect Hal followed a very rigorous process, in his head, instinctively, subliminally, and very quickly. If we could clearly identify the steps that Hal followed informally, we could document (or formalize) a process for everyone to follow. It might look something like: write down all the requirements, brainstorm and list all possible solutions, then rate and rank each candidate on how well it meets the requirements and select the candidate with the highest rank. With a formalized process, everyone could make decisions as well as Hal; well, almost as well, since the transformation from instinctive process to formal process to execution is never 100% efficient. But we could raise everyone's proficiency. Everyone's, of course, except Hal's. If we forced Hal to follow this process, he would waste time writing down all the requirements, identifying subject-matter experts, holding brainstorming sessions, writing all the options on pastel-colored 3x5 post-in notes and filling the walls of some conference room, drawing four- and five-dimensional diagrams relating all of the requirements to all of the options to all of the costs, and selecting the optimal solution based on a secret ballot of all stakeholders. What used to take Hal a few seconds or minutes of cogitating would now take him days just to get a conference room reservation. Hal's productivity would drop by orders of magnitudes. The purpose of formal processes should be to compensate deficiencies while not hindering proficiencies too much. When applying a new process (or changing an existing process) there needs to be a net gain, a reason for the change, a "big payoff." A "good" process may not be good for everyone. And every process needs to be flexible so that it can be adapted and taylored to the organization, or the individual. Formal processes and process change is not the panacea for all problems. To paraphrase an oft mis-iterated quote of Ralph Waldo Emerson:
[Appologies to Mr. Emerson.] The first step in improving processes is to understand the processes that are in place, formal or informal. If there are no formal processes, the first, critical, step is to formalize the existing processes, exactly as they exist, without embellishment. The last thing you want to do is formalize a process and change the process at the same time. For example, I once worked at a small company with a team that performed very well with no formal processes. None were needed. As the team grew, new members needed to understand how things got done. So we set out to document the software change control process. The first attempt was a bit over-zealous, and resulted in a dozen-step process, with reviews, checklists, approvals, etc., which simply did not exist (and did not need to exist). That version was torn up and replaced with what was really happening:
The process made clear what was expected of the developer, without creating artificial hurdles or pointless documentation. This process worked fine, and continued to work well for a long time, because the team members were very conscientious and could be trusted to do the "right thing". If you trust your team members, then your processes do not need to be onerous; they do not need to include checkpoints and approvals (and if you don't trust your team members, perhaps you need new team members). Much later, when the team had grown and the rate of changes (and the rate of mistakes) increased, we did go back and change the process, evolve the process, in ways that improved overall efficiency at a modest cost. But we could not improve the process until first we had formalized the process. Posted at 12:02PM Dec 21, 2006 by Robert Hueston in Sun |
Tuesday Dec 19, 2006
Methodologies, Processes and the Silver Bullet According to most dictionaries, the definitions of "methodology" and "process" are virtually identical; however, some people, engineers in particular, ascribe very different meanings to the two words. Processes are imposed from above; methodlogies are adopted from below. Processes are obeyed; methodologies are adhered to, sometimes religiously. Processes are onerous; methodologies are liberating. Processes are often circumvented; methodologies are staunchly defended. But I think the basic difference is: Processes are someone else's methodologies. If the government had only devised a methodology instead of a process for paying taxes, people would be wearing tee-shirts extolling the virtues of the "IRS Methodology". The Silver BulletA couple of years ago I was fortunate to attend a presentation by Sarah Sheard, Chief Technologist of the Systems Engineering, Systems and Software Consortium. The presentation was entitled "Systems Engineering and Silver Bullets" which told a "fable" that went something like this: The CEO of a company is unhappy with all of the existing methodologies and decides to come up with a methodology that uniquely works for his company. He involves his managers and employees to come up with this new process. Productivity and morale skyrockets. Several other companies are impressed by the increased productivity. They dispatch senior managers to study the new methodology, and carefully adapt it to their own companies. These companies see positive improvement, thus confirming the new methodology Many more companies decide to adopt the new method. They assign middle managers to implement the new methodology, as best they can, in a short period of time, knowing only what they've read in articles. Managers, in turn, force the changes onto their employees without accepting feedback. Improvements are marginal, and morale sinks. The lack of gains and decrease in morale are cited as examples that the new methodology does not work. Books are written debunking the new methodolgy. The executive of another company is unhappy with the methodology and decides to come up with a methodology that uniquely works for his company... [A more complete version of the fable can be found at http://www.stsc.hill.af.mil/Crosstalk/2003/07/sheard.html.] The moral of the story is obvious -- there is no silver bullet, no single methodology or process which will improve efficiency at every organization. A methodology must be embraced from the top of the organization to the bottom, and care must be taken to taylor any methodoogy to the organization, based on measurable performance improvements and individual feedback. Only then will a methodology really be successful. On the other hand, if you buy a book on a methodology and force people to follow it, you will probably fail. I have seen this many times -- what works for one organization does not work for another; this can even be true for two workgroups in the same company. Methodologies must not be rigid; they must allow for tayloring to an organization, and to workgroups within an organization. Copyright 2006, Robert J. Hueston. All rights reserved Posted at 12:40PM Dec 19, 2006 by Robert Hueston in Sun | Comments[1]
Monday Dec 18, 2006
The Golden Axiom of Learning Leadership Since I started leading projects back in the 80's, I've learned one golden axiom that has proven true in all cases. In the past I have generally only shared this with my closest peers:
The first part, learning from your mistakes, is well know. The second part of the axiom, learning from others' successes, is less well appreciated, but I find it to be just as true. People learn from watching and mimicing behavior. If you watch a person performing well, succeeding, handling problems calmly and analytically, then you will learn those behaviors yourself. If it weren't true, then we would have no hope of learning except through mistakes, and I'm pretty sure that would have meant the end of the human race a long time ago (and Harvard wouldn't be able to charge $35K per year tuition). Clearly we must be capable of learning from good examples. In addition to the golden axiom, there are a couple of subtleties that most people overlook. I call them corollaries:
Corollary #2 goes hand-in-hand with the second half of the golden rule. Humans learn from watching others. We can learn to succeed from successful people, and we can learn to fail from failures. But we don't learn to be smart by watching fools. Studying a child can be a good way to learn about adult behavior. Children do things naturally, in an uninhibited fashion; adults often try to obfuscate their actions and motives, but they really behave in much the same was as children. To demonstrate corollary #2, consider Caillou. Caillou is a cartoon on PBS, about a four-year-old boy of the same name. My 3 1/2 year old daughter loves the show. When Caillou is good, she mimics his behavior and she is good; when Caillou is bad, she still mimics his behavior. As an example, my daughter likes baths. But one day Caillou didn't want to take a bath. He cried and whined, but once he got in the tub, he loved it. Clearly the message was supposed to be, "Don't cry at bath time because baths are a lot of fun." But for a week after watching that show, my daughter would cry and whine at bath time. She had observed the poor behavior of Caillou on TV, saw that it was wrong, but still she modeled her own behavior on what she observed in others. I've seen this same sort of thing in adults as well, sometimes even in myself. When I was a new college grad I had one manager who would pass out a list of tasks that each engineer should be working on that day. My peers and I just hated the micromanaging -- we used to work on low priority tasks first just to tick off our manager, and we set up a dart board in the lab where we posted the daily task lists and took aim. A few years later, I was the leader of a fairly large project, and was having trouble keeping all the work straight, when I found myself writing up daily task lists for my team members, and was met with a small mutiny. When I was faced with a challenging situation, I mimiced a behavior I was familiar with, despite knowing how poorly the approach worked. But that was the "training" I was given, the only "tool" I had. I only learned the lesson once I had made the mistake myself. [Corollary #2 poses a unique problem when writing about leadership. An author, in fact any mentor, and even a parent, wants to share their mistakes, desparately hoping others will avoid making the same mistake. But it's a futile goal, and in fact, it can backfire quite badly as the observer may be drawn to make the same mistakes. Ever tell a child, "Don't touch that!" Odds are, their little hand will immediately start to reach out for it. I suspect at this very moment there are a few managers out there who read this blog and are thinking, "Hmm. Daily prioritized task lists? Maybe I should try that with my team." And probably at least one engineer is going to whine tomorrow morning when he has to take a shower. In the future I will try to avoid dwelling on mistakes, and concetrate on successful behaviors.] Knowing the golden axiom and its corollaries, we can develop a set of personal principles we can take with us:
There's also a couple of rules that organizations need to internalize:
Posted at 11:29AM Dec 18, 2006 by Robert Hueston in Sun | |
|
||||