Waging Project Management Warfare
What your daily work has in common with combat - it's more than you might think and not as bad as it sounds.
Jennifer Glen
Solien Technology, Inc.
July 2002
Summary: Applying principles of warfare to software project management.
Recently, I took a hiatus from my job as a project manager at a software development company to attend a three-day, intensive self-protection class taught by a former Navy Seal, Richard Machowitz. Despite the fact that majority of the class was spent running eye-poking, groin-kicking and nose-kneeing drills, I kept finding myself comparing the experience to software project management.
Did it surprise me that a self-protection class based on combat principles reminded me of my daily work? Not exactly. The signs of project management and warfare convergence have been all around me, from Gantthead's "Project Management According to Napoleon" (Jerry Manas) series to one of my favorite project management books, Software Project Survival Guide (McConnell 1998).
On the first day of the course, our instructor introduced us to the Three Dynamic Elements of CombatT. These elements, which apply to all types of combat, are targets, weapons, and movement. Specifically:
Targets dictate Weapons
and
Weapons dictate Movement
Here is a simple example he uses to illustrate the concept. Go turn off your office light. As you will notice, you didn't need anyone to tell you what hand or what motion to use to do it. You simply had your target and were able to instinctively choose the weapon and movement necessary to "take down the target."
Now think of a software project. Replace targets with objectives or goals. Replace weapons with resources (human or technical). Replace movement with process or practices. So,
Goals dictate Resources
and
Resources dictate Process
In software development, we start with a vision statement, from which we can distill a set of business goals or objectives and finally arrive at requirements. These are our targets.
Once these are set, we can start the weapon selection process. I like to think of weapons as people and technologies. And personally, I would rather see my name listed as a "Weapon Name" instead of a "Resource Name" in a Microsoft Project plan. Let's face it; project management terminology just isn't quite as fun as combat terms.
Last, we arrive at movement or process. The fact that this comes last is an important distinction, especially given the recent rise to popularity of agile methodologies. The whole chronology is an apt reminder that the objective needs to drive the project. Everything else - the resources and methods - follows. This seems so obvious, yet sometimes the project team's desire to work with a specific technology or try out a new practice will supersede the basic objectives.
Machowitz makes this point well in his class when he demonstrates some of the more intricate moves employed by martial artists. These actions may be impressive, elegant and effective. However, to be effective they have to hit their target. And often, you don't need to be impressive or elegant to be effective. A kick to the groin may be just as effective as a supporting foot lift-pull throw, and a lot quicker to master. I couldn't help thinking "developer gold-plating" during this demonstration.
Clearly the project targets are important. But that doesn't mean that defining those targets is easy. It can be difficult to facilitate a process with the project stakeholders that allow them to arrive at an exclusive vision and prioritized requirements for the project, both of which are important in mitigating project risk. We often find that our clients are either unwilling or unable to prioritize - everything is mission-critical!
In addition, successful project management requires that targets are assessed throughout the project life cycle. Such assessments are at the heart of active change control and risk management procedures.
Here we can also find some help from the Navy Seals, who are taught to use the CARVER matrix to assess targets in their Special Operations Target Analysis Studies. CARVER, an acronym for criticality, accessibility, recognizability, vulnerability, effect on overall mission, and return on effort, is equally applicable to target assessment in software development. Below I have adapted the definitions of each item to apply more directly to software project management.
Criticality: How vital is this to the overall objective of the project? If we do this, is it going to contribute to the ultimate objective?
Accessibility: How easily can we get to this target? How easy is it for us to hit this target?
Recognizability: How easy is it for us to find this target? How easy or difficult is it to recognize the things we need to do to knock this target down?
On first glance, this doesn't seem as applicable to application project management as criticality or accessibility. After all, software development teams are not typically seeking out camouflaged targets in highly wooded areas. But think about it in terms I have often heard developers use to describe the nature of some software problems: "you don't know how to solve the problem until you solve it." This is a perfect example of the type of problem where it is difficult to recognize the things that need to be done to knock this target down.
Vulnerability: How much time and what kind of resources are needed to hit this target? Can this easily be finished within a certain time frame and by a certain number of people?
Effect on Overall Mission: How much closer will this move us to achieving the overall vision?
Return on Effort: What is the return on initial investment of resources, and when will we see it?
For a client services organization such as my own, this is sometimes an important consideration. It may be advantageous to tackle a target that will yield a highly visible (e.g., has a user interface that is accessible to client) and satisfying result for our client before an equally challenging but less visible area of functionality.
Here's an example of how a change control board meeting to evaluate new feature suggestions might use a CARVER matrix. Each new feature is listed, and assigned a value of 1-5 for each element of CARVER, with 5 being the most valuable and/or easiest to attain, and 1 being the least valuable and/or the most difficult to attain.
Table 1: Carver Matrix:
|
New Features/
Functionality |
Critical |
Access |
Recognize |
Vulnerable |
Effect |
Return |
Total |
|
Email Alerts |
2 |
4 |
5 |
4 |
2 |
3 |
20 |
|
Sorting |
2 |
5 |
5 |
5 |
2 |
2 |
21 |
|
Search |
3 |
4 |
5 |
4 |
3 |
3 |
22 |
|
New class of user |
4 |
2 |
2 |
2 |
4 |
4 |
18 |
The totals sometimes reveal interesting results. A feature suggestion that was a mere afterthought may turn out to be a bang-for-the-buck move for the client. By prioritizing targets throughout the project lifecycle, we keep things simple for all stakeholders. It is much easier for all involved to see where the project is and where it is going.
Questions? Comments? Suggestions? Please send correspondence to jennifer@solien.com.
Note: This article is a field-specific (software project management) application of military concepts found in the published work of Richard Machowitz, Unleashing the Warrior Within. These include the Three Dynamic Elements of CombatT, whose trademark is held by Machowitz's self protection training organization, the Bukido Institute.