Tactical Leadership : Weblog

Monday Apr 02, 2007

Know your enemy

Sun Tzu advocated: Know your enemy. In software project leadership, the first step in leading a project is to identify the enemy. The enemy may take several forms, and must be addressed in different ways. Once the enemies are identified, they can be scoped, and plans made to combat the enemies.

Potential Enemies

The following are several of the common enemies a project leader must fight. This is by no means a complete list; it is intended to start you thinking beyond simply writing code.

A. The Problem

I took a graduate-level discrete math course some years ago. The professor (I honestly forget his name) started the first class by saying, "Don't ask me how to apply this to the real world. This is a class in math. One plus one; that's math. One orange plus one orange? Well, that's physics." That lead me to realize my own definition of the physical sciences:

Engineering exists to solve problems and improve the world. So the fundamental reason for any engineering project must be to solve a problem. However, many engineering projects suffer because they don't know what problem to solve, or they solve the wrong problem.

There a numerous methods of identifying the problem. Requirements analysis. In-scope/out-of-scope charts. Prioritized features lists (with must-haves, nice-to-haves, and non-requirements), and so forth. This area of engineering is well discussed in modern literature (although still many projects fail to take the time to define the problem before they start), so I won't belabor it in this blog. But I will raise one point.

Rarely is a problem really solved unless the solution meets or exceeds the customers' expectations. In the commercial world it's impossible to talk to all the customers (and even if you did, they'd all have widely different expectations). However, I've found that reasonable proxies for the customer are the employees who work with the customers -- field service engineers, application engineers, etc. Typically, they meet enough customers to know, in general, what their expectations are, what minimum features are absolutely required, and what will really knock their socks off. I like to have a Service Engineer on my project team, fully engaged, attending every meeting, and intimately knowledgeable of the product we're developing. When a question comes up about how a feature should be presented to the customer, I turn to the Service Engineer (who in turn consults with other Service Engineers in the field) to choose the best option.

B. Process Snags

I've seen many projects suffer because they did not fully identify the process requirements in advance. Many process requirements stem from corporate quality initiatives; others are just common sense. Some examples of process requirements include:

Reviews (requirements, architecture, design, code, etc).
Testing requirements.
Certifications/qualifications.
Sign-offs and approvals.

I've actually been on projects where we got near the end of development with only a few weeks to go before release, only to learn that there was a process step we didn't know about -- a review to get approval to start development. And the committee that approved projects was booked for the next two months. Issues like that can be overcome by expediting the process, bumping other projects off the agenda, or scheduling an emergency review meeting, but those options bring added cost, both monetary and good will.

Understand and identify all of the process steps required by the company, customers, and government regulations, and plan for them in advance.

C. Deal Makers/Deal Breakers

In my own experience I have found that no one person can guarantee your project will be successful. However, I have found cases where one person can guarantee your failure.

Deal Makers are the people who can help you succeed, if you get them on your side. And if you don't get them on your side, they can often prevent you from succeeding by withholding critical approvals, or convincing those in approval positions to delay approval. They become Deal Breakers.

When looking for these Deal Makers/Deal Breakers, ask yourself:

Who will use the product?
Who will build it?
Who will test it?
Who will service and support it for customers?
Who needs to approve it?
Who supplies the money? The people? The resources? The lab space?
Who's opinion carries a lot of weight with the other people listed above.

Getting a Deal Maker on your side is often very easy:

Identify and engage them early in the project.
Share with them your thoughts and plans.
Seek their input, and thoughtfully apply their input or provide feedback why you could not.
Keep them informed of changes; make them feel a part of the team by making them part of the team.
If they feel like a valued part of the extended project team, they will work to make the project a success.

The enemy described here is not the Deal Breakers; they can either make or break your project. The enemy is within. If we fail to identify Deal Breakers and convert them to Deal Makers, we are our own enemy.

D. Organizational Miscues

Any large company has significant organizational communication requirements. For example at Sun, a project delivering a feature into Solaris must:

Notify technical publications to schedule man pages and other Solaris document changes.
Notify the internationalization department so they can schedule localization of all text output.
Work with the team that creates packages to make sure your new files are delivered and installed properly.
Contact the legal department if there are any patentable inventions.
Work with the organization responsible for the Solaris product to ensure that the project schedule aligns with Solaris build and release schedules, and the project satisfies all Solaris quality requirements.

and so forth.

Small companies, on the other hand, aren't so lucky. Their organizational communication channels almost always span companies -- publishing companies for their documents, translation companies for localization, companies that build and distribute their product, etc.

Regardless of whether the organizations are internal or external, they must be identified early and addressed in planning.

I've seen projects work toward their own schedule, only to discover they forgot about technical publications. They're almost done, but no one has written man pages or customer documentation. The product release gets delayed while waiting for the other organization, in this case Technical Publications, to catch up. Leaders who forget to communicate with other oragnizations will often blame the other organization ("We're waiting on Tech Pubs" or "Our ship date got delayed due to the Solaris release team."). The other organizations aren't to blame; the leader is, for failing to openly and fully communicate with the other organizations. A product is everything -- the software, the documentation, the release vehicle -- and a project leader is responsible for making sure all aspects of the product are coordinated, regardless of which organizations are involved.

E. Quality

Of course, "quality" is not an enemy; it is a goal. However, I couldn't find a suitable antonym to "quality." Technically, "defectiveness" is probably suitable; "non-conformance" is perhaps the most appropriate. Whatever you call it, allowing defects and nonconformities to advance through the development cycle is a dangerous and costly enemy.

I could easily write an entire blog entry (perhaps an entire book) on how achieve quality, but suffice it to say that the methods of achieving quality must be addressed early, planned, resourced and executed in order to ensure a quality product. Some of the common initiatives in a software development project include:

Requirements Inspection: Are the requirements consistent, complete, and address the problem?
Design Inspection: Does the design achieve the requirements?
Code Inspection: Is the code written to the design?
Unit Testing: Does the code execute as written?
Integration Testing: Does each unit work together as designed?
System Testing: Does the product perform a required?

I will go into the differences between inspections and reviews in a later blog entry.

F. Inertia, Brownian Motion, Entropy and Chaos

Often a problem is identified, but getting it fixed requires overcoming inertia -- it often can be far easier to live with a problem than mobilize effort to fix it, especially when that problem is not affecting you directly (though it may be affecting your customers, your service organization, and your sales organization). A good leader needs to be a motivator, and drive the team to overcome inertia and get the job done.

In high school physics, most people learn that inertia is the tendency of a body at rest to remain at rest. It takes some external force to overcome inertia and get the body to move in a new direction. The second part of the principle of inertia is that once a body is in motion it will tend to stay in motion in a straight line.

People, however, do not fully adhere to the laws of motion. While at rest, they do tend to stay at rest; however, once a team is in motion in a coordinated and well planned direction, if the driving force is removed, the team members tend to either return to a state of rest, or worse, they tend to exhibit Brownian Motion -- wandering off in random directions, sometimes pursuing contradictory goals, and often bumping into each other and expending pointless energy. Over time, entropy sets in and the entire team digresses into chaos.

The term "project leader" is somewhat of a misnomer -- a leader must not only lead, they must push (however, the term "project pusher" isn't much better). A leader with no followers is a failure. A leader must be able to provide the impetus to drive the team forward, and channel the energies of the team members in a coordinated manner to attack the problem at hand. Inertia, Brownian Motion, entropy and chaos are the enemies of leading people.

G. The Hidden Enemies

Have you ever been burned by something, and someone says, "I knew that was going to happen"? Well then why didn't you warn me?!?

One thing I've learned is to periodically (initially monthly, later quarterly) bring the team together and ask each and every person, "What do you worry about?" And I expect an answer, a list of enemies, from each person. Sometimes people will respond that they don't have any worries, but when you force them to think, the worries come out, and the enemies emerge. Sometimes they are just shadows; other times they turn out to be real issues that need to be addressed immediately. You can't fight the enemy you don't know about, but once they're out in the light, they can be defeated.

Not Enemies

In addition to the above potential enemies, there are a couple of things which are not enemies that I wanted to address here.

A. The competition

Perhaps in sales and marketing, competing companies can be considered enemies. We try to get products to market faster than the competition, that are better than the competition's products, and cost less than the competition's products (that is, cost us less to make, even if we charge our customers more). In engineering the competition is a competitor; however, it is not an enemy. Apart from industrial espionage and sabotage, the actions of the competitor do not affect our time to market, our quality, or our cost. We can blame the competition for our loss, but in reality we only have ourselves to blame.

Often, the competition can actually be a collaborator. Engineering is the application of science to solve problems. If the competition solves the problem first (and shares the solution), that can be to our benefit. Industry working groups, standards organizations, etc., are key examples of the collaboration between companies to solve a problem, while they compete to develop and release products based on that collaboration.

B. Process

In high school I was a high hurdler on the track team. My coach used to tell us, "The hurdle is your friend." The job of a hurdler is to run down the track, leaping cleanly over the hurdles. You have to work with the hurdles. If you try to mow them down, like they're the enemy, it only slows you down and you will lose.

Far too many leaders view process as the enemy. An enemy is something you attempt to defeat or avoid. When you work to defeat or avoid required processes, they you're wasting your energies.

Recon

Knowing the enemy implies more than just knowing who the enemies are. We must quantify their location, strength, capabilities and intentions. The military accomplishes this through surveillance and reconnaissance; the former is passive, while the latter is active. I think most people rely far too much on surveillance, for example, past experience, and observations from other people. Instead, we need to actively go out and patrol for the enemy.

Examples of active reconnaissance include:

Prototype critical aspects of the design. A quick prototype can uncover unexpected problems before too much time is invested in a detailed design.
Communicate with process owners to make sure you understand the process requirements, and how the process may be tailored to your advantage.
Contact organizational leaders and identify their requirements.
Engage deal makers/breakers to understand what it will take to gain their support and bring them into your team.
Motivate and orient the team, early and often.

Respond In Force

Once you know the enemy, you can prepare an offense. The information we learn about our enemy must be brought forward into the project planning. We must allocate resources to combat the enemies, all of the enemies. We must proactively engage and defeat the enemies and not sit back and wait for them to engage us. Success must be achieved; failure comes with little effort.

Posted at 09:05AM Apr 02, 2007 by Robert Hueston in Sun | Comments[1]