Out of Overload

A Guide for Technical Managers

Chapter 5
Overloaded Missions

Modeling
A Couple of Rules

Interactions
On Priorities

Mission Structure
Project Tracking

If you work through the consolidation steps and still end up with too many missions, youíre setting yourself up for overload. Another level of analysis is required. Typically, this means modeling the missions and understand their interactions in greater detail.

Modeling

Modeling the missions surfaces opportunities for leverage and collaboration.

In order to see overlap possibilities, mission interactions must be clear in your mind. This means engaging your visual senses.

Sketch out the missions, connecting any exchange points. Draw in the key aspects of each mission. Putting the concepts on paper gets them out of your head and allows you to "see" the interactions.

For more in-depth coverage of the modeling process, check out Chapter 7.

A Couple of Rules

Simply modeling your mission may not be enough. Complicated situations can result in models where too many concepts create a maze instead of a map. If your models are confusing, you need to restructure them according to the following grouping rules.

As explained in the Accelerated Learning section, staying within grouping limits makes it easier for your mind to accept and consider information. These limits are best stated with two rules:

1. Groups of three for decisions.
2. Groups of seven for listings.

1. Groups of three.

If you are deciding between more than three courses of action, you need to shape them into groups of three. With groups of four or more the ability to fully consider their interaction decreases.

For example:

Edís mission was to refocus the department on a lower cost product. His model included the following sections:

- Setting performance goals.
- Upgrading the CAD system.
- Training the staff on rapid design tools.
- Putting together the budget.
- Recruiting.
- Verifying the design with market research.

Even though the list wasnít that long, it was confusing when he considered it all at once. To consolidate the items he marked similar sections.

** Setting performance goals.
++ Upgrading the CAD system.
++ Training the staff on rapid design tools.
&& Putting together the budget.
&& Recruiting.
** Verifying the design with market research.

Regrouping these into three larger groups produced three summary categories:

Design
** Setting performance goals.
** Verifying the design with market research.

Tools
++ Upgrading the CAD system.
++ Training the staff on rapid design tools.

Administration
&& Putting together the budget.
&& Recruiting.

For the Low Cost Product mission, the sections reduced to:

- Design Issues
- Tools
- Administration

With this reduced format, Ed intuitively understood the scope at a glance. The restructured model allowed him to consider the Low Cost Product in conjunction with other missions without going into overload.

Active decision making must involve three or less categories.

Note: The Three Rule stems from a study of chess masters and their decision making. It seems that even though the masters had thousands of moves available to them from their years of play, they only considered three options at any given time. The concerns might be: protect the queen, set up an attack on the king side, and keep an eye on the exposed rook. The inference was that three decision groups are optimum. (The research citation for this study is not available at this writing. My apologies to the authors. - JAD)

2. Groups of seven.

If the line items are similar and make up a simple list, they can include up to seven items. Where the "three's" groups are decision-oriented, the "seven's" categories are a things-to-do variety, a laundry list.

Since the options are either seven or three, the rules lend themselves to a simple procedure. Always regroup and reshape your missions until you have seven or fewer groups. If, for any reason, seven categories seem cumbersome, reshape them down to groups of three.

Interactions

Once you have the missions sketched out and grouped in a way that doesnít produce overload, itís time to identify their interactions. These interactions might include:

- Passes information to.
- Waits for.
- Supports.
- Helps.
- Uses the same type of data.
- Accelerations.
- Organizes.
- Pays for.

From your list of interactions identify dependencies, facilitators, and minor affects.

Dependent: - Pays for.
- Waits for.
Facilitates: - Supports.
- Passes information to.
- Helps.
- Accelerations.
Minor: - Monitors.
- Organizes.
- Uses the same type of data.

These interactions should suggest coping strategies. If one mission is holding up everything else, obviously it should get early attention. Look for dependencies. Some of your findings will resemble traditional project analysis forms, i.e., PERT.

Facilitators are important. Because they have a multiplier effect, even minor increases facilitating missions can produce improvements across all your projects. For instance, an hour on one area might generate the equivalent of two hours on each of five other missions.

For example:

Anne saw her leverage points right away:

1. Generalize the database to accommodate two other departments.
2. Creating an OCX for the common tax adjustment.
3. Make the adjustments configurable.
4. Make the unit field upgradable.

Occasionally, you will find yourself with a mission that has no real interaction with other missions. It has no opportunity for leveraging. You need to off-load these missions. If someone else canít take it over, find a way to put it on hold. You want to be spending your time on those things that have a ten-fold, a hundred-fold return.

On Priorities

In technology environments, the words "top priority" rank up there with "mission statement" and "dress code." Years of misuse have given anything labeled as a priority a bad name.

For example:

Bob laughed. "One of my product managers would repeat, 'They are all top priority,' each time I said there wasnít time to do all five."

-----

Ed didnít find it funny. "Whenever the 'priority' word surfaces it means pushing through a poor design and accepting out-of-spec parts because there isnít time to send them back. On top of that, I'll probably have to work through the weekend for the next two months."

Because priority issues cause so much frustration and overload, itís worth considering coping strategies.

Letís go back to the basics. If your missions are well structured, and you are getting a hundred-fold leverage from your efforts, you will be successful. The massiveness of your efficiency will roll over office politics, difficult customers, and fluctuations in the market.

The benefits of traditional priority setting are addressed by your analysis of mission dependencies. One task fits before another; information flows in a certain way. This flow sets the real priorities. By identifying the mission interactions, you are building a multi-dimensional system of leverage points. These interactions and dependencies combine into a dynamic network of optimized workflow.

Unfortunately, priorities are often driven by forces outside of the technical model, and they may not have a feedback path to correct shortsighted views. When a "high priority" item lands on your desk, itís all too often driven by a single sales opportunity or political positioning.

For example:

Priority was a dirty word to Bob. It meant he had to pull resources from what he felt was important and handle someone elseís problem.

It seems like "high priority" translates into little leverage and no connection to your key missions.

Commonly, this conflict stems from a lack of mission coordination at the highest level of your organization. There is little you can do about that. Most companies have a web of financial and political dynamics that those on lower levels canít budge. It will cut down on your stress if you donít fight it.

For example:

Lou tried to be philosophical: "Every soup has a couple of bones. Just spit it out."

In todayís corporate environment, "high priority" distractions are a reality. Given their inescapablility, you might as well give them pseudo-mission status. For example, you may bundle your "top priority" administrative assignments into a mission headed "improve your public speaking skills." You get a benefit that makes sense, and the requests become less irritating.

For example:

"So," Lou said, "it wasnít a bone after all. Just turn it into a piece of potato. Thatís clever."

Mission Structure

When it comes to organizing mission details, two structures stand out:

1. Mission Structure.
2. Project Tracking.

Mission Structure focuses on the big picture, and Project Tracking focuses on tasks already in progress.

The mission structure consists of four stages:

1. Defining the mission.
2. Listing the goals encompassed by each mission.
3. Detailing out a plan for each goal.
4. Listing the tasks to implement the plan.

Serious missions require this level of planning and analysis. It forces you to recognize the scope and commitment needed to accomplish the mission.

Creating a Mission Structure plan takes time. If youíre already in overload, there is a good chance youíll never make it through the entire planning process. This continues to give planning activities a bad name: "It takes too long." Thatís true, but if you skip the planning functions, youíll regret it later. The lament quickly changes to: "Why didnít we think of this before."

Unless you have extraordinary discipline and a very patient executive team, youíre not going to have enough time to fully plan your missions. However, that doesnít give you license to dump any thought of planning once a project moves forward. Start the project, if necessary, but continue with the planning process.

Because of the time needed for a complete set of mission plans, treat it as one of your projects. This will break down the steps into small tasks and allow you to complete the plans gradually, without bringing other activities to a halt. As long as your planning effort is regular, it isnít critical that you have closure on every item before the action begins.

Project Tracking

Projects are the soul of an organization. They are the force that produces bonuses and causes heads to roll. Financial results, commissions, quotes, and performance forecasts all connect to project results. From the most junior sales rep, to the corporate chambers, everyone has a vested interest in whether projects are on track.

The sequential nature of project events means that they usually move forward without too much oversight. However, with their visibility, it makes sense to pay close attention to their key elements.

The elements of project tracking:

1. Event tracking.
2. Status.
3. Dependencies.
4. Timing/coordination.
5. Scheduling.

Most projects boil down to a collection of events that unfold in simple sequences or in parallel. Even though any single event can be quite complex, the overall flow is straightforward.

1. Event Tracking

Every person involved in a project should have a sketch of the events with the sequences clearly described. Hereís why. Most people in overload are involved in a variety of efforts. That in and of itself isnít bad, but it becomes a problem when the events all come due at the same time. With the proper foresight, you can spread the events out. Most bottlenecks are avoidable.

Bottlenecks drain time from everyone. When time crunches hit, days fill up with emergency meetings. As a cruel twist to the reward system, those who have diligently organized their own efforts are reassigned to the tasks that are past due. All parts of the system begin to breakdown.

Itís in everyoneís interest to keep the projects flowing. For that reason, every person should help identify obstacles as soon as possible. Sitting back and waiting for the train wreck hurts everyone. This doesnít mean you need to run every project. It means you should examine your sketch of events and push those areas that you know are a likely source of delay.

2. Status

With the attention focused on projects, you should stay apprised of any status changes. This also gives forewarning if your task is needed early.

For example:

Because the projects never seemed to track to original schedule, Linda never knew when things would hit her desk. It felt like they came in all at once, each with urgent billing.

Linda found that by loosely tracking all related projects she got just enough forewarning to have the prep/setup work ready as the task hit. Some thought she was a bit nosy, but it worked. With a little negotiating and shifting events, she was able to maintain a reasonably smooth work flow.

3. Dependencies

In the project flow of events, dependencies have the potential to be disruptive. Letís say that youíre ready to finish your coding, but the test unit was never ordered. Two weeks are lost for no good reason.

Again, this works best as a shared responsibility. Stay aware of major dependencies. If necessary give your fellow overloaded workers a "heads up" when you see a bottleneck moving in their direction. Traditional PERT and project management tools can be quite helpful in tracking these dependencies.

4. Timing/Coordination

Where dependencies address large requirements, day-to-day coordination handles the little acts of cooperation that make things go smoothly. The best technical teams are very good at sharing the right pieces of information.

For example:

Tony knew the hardware group was depending on his 12 firmware fixes, and he planned on delivering those right on schedule, in three weeks. While waiting for a staff meeting, he learned that if Linda got the first three items early, she could get a head start on her tasks. Two hours later, he passed her the changes.

5. Scheduling

Too many technical people consider scheduling the "S" word. It probably goes back to times when they were given unrealistic timetables and then badgered until completion. All too often, brilliant technical feats are clouded by the statement: "It was late." Itís no wonder that scheduling has a bad name.

Regardless of its reputation, scheduling is a necessity for anyone in overload. The trick is to handle scheduling in a way that doesnít contribute to your workload. As a first step, this means getting dates and sequences out of your head. Get them into your central reference. Once they are out of your head, you can use the project tools of your choice.

Because scheduling affects every element of a project, itís worth becoming proficient at it. When things come in early, try to understand why. When things are late, look for the real causes.

Many technical people want nothing to do with project management. It seems so political. However, if you consider how much energy is wasted when a project loses coordination, it's clear that scheduling and timing need attention.

6. Monitoring

Itís impossible to coordinate your missions in one pass. Too many things change every day.

With the high flux in technical environments, some form of oversight is necessary. This should include a regular mission review to see if your view of two weeks ago remains valid. Similarly, this lets you evaluate what is working well, what needs adjustment, and what parts you may have overlooked.

For example:

Louís study program was going nowhere. Every night heíd doze off two pages into the work. Without getting critical, he acknowledged that he was too tired in the late evening to study effectively. Lou accepted that fact and started going to bed an hour earlier. Heíd try to study for an hour in the morning.

You need to be very easy on yourself during these reviews. The idea is to make adjustments, not berate your current practices.


Go to: | AWSS Main | Previous Chapter | Next Chapter | Feedback: jdavis@awss.com