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.
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:
Math is the study of numbers.
Science is the use of math to explain the world.
Engineering is the use of science to improve the world.
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.
- 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
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
- 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.
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.
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
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.
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
Copyright 2007, Robert J. Hueston. All rights reserved.