No matter how much we might believe in the principles and practices of good project management, there are still many organizations out there that view PM as nothing but unnecessary overhead. Here are a few suggestions from the nimble project manager’s toolkit on how to quietly get a project organized and headed in the right direction using the principles of stealth project management.

Stealth project management means doing the minimal amount of PM necessary to get the project done without calling a lot of attention to the process. The trick is to understand that management is in full support of a well-run successful project. What they don’t want is bureaucracy, form for the sake of form, and activity rather than results.

The first place to start with stealth project management is to understand the three golden rules:

  • Keep the focus on tangible results, not activities. In its simplest form, this strategy means not making the mistake of telling management you can’t do something because you’re too busy planning, updating the schedule, or writing up some report. It means not locking yourself in your office but being available to the team to do whatever needs to be done.
  • Fly under the radar. In order to successfully practice stealth project management, you must have a good understanding of the current company culture. Every organization sets different lines between effective processes and bureaucracy. The art of stealth project management requires tailoring your approach to PM to avoid triggering bureaucratic warning bells.
  • Beg forgiveness rather than ask permission. Stealth project management requires being so comfortable and so knowledgeable about the PM processes you have decided are necessary that no one ever thinks to question why you’re doing what you’re doing.

So, how much project management can and should be done on a stealth basis? It depends on the company culture, but here are some thoughts of what might work.

Create an initial area of order
Get clarity on the constraints of the project before you begin. This step can be brutal for a PM since it usually means finding out that management wants the project sooner than you think is reasonable, for a lot less money than you think it will take. Your goal at this stage is not to argue but to get an idea of what is important to stakeholders and why. In most development projects, the goal of the project team is to solve a problem as elegantly and as creatively as possible (after all, this is the fun part of the job), while the goal of the company is to solve the problem simply, at the lowest possible cost, and in the shortest time frame. Simply recognizing this inherent conflict does more to ensure that the project can be run to meet expectations than any other activity.

Get agreement on the appropriate level of risk in the project. Some projects, by their very nature, need to be low risk (such as a new payroll system or an infrastructure roll-out), while others can and should be experimental and cutting edge. At the beginning of the project, you should quickly get a feeling for any known project risks and compare the potential severity of these risks to the acceptable risk level you’ve assigned to the project. If you decide that any of these risks need to be mitigated, the trick in a stealth environment is to roll the mitigation into your initial project plan.

Objectively assess your sponsor and stakeholders. Since this step can be done in the privacy of your own head, there’s never any reason not to do it. One of the single greatest reasons for a project to fail is lack of solid sponsorship. You owe it to yourself to know if you’re in trouble before you’ve even started. If you are, see if you can quietly shop for another sponsor. If that isn’t possible, objectively assess what the ramifications of a weak sponsor will be and try to miss those potholes. Most of the time, the lack of a strong sponsor can create a situation where the requirements and the scope of the project change so often that the team ends up feeling like they’re working on a merry-go-round. Forewarned is forearmed.

Develop a scope statement. This can range from a paragraph in an e-mail to a one-page document, depending on the tolerance of the organization. Write this up at the beginning of the project and send it to all interested parties, saying this is what you think the project is intended to do and ask if they agree. Your goal at this stage is to bracket the outer edges of the project, not to define the details.

A very experienced practitioner of stealth PM I know once challenged this as a minimum practice on the grounds that it would come very close to violating the culture in his company. The best response he would get would be to have the e-mail ignored. The answer to this is really an issue of short term or long-term focus. In the short term, I agree it might not matter. In the long term, skipping this step when it’s not of critical importance may cost you your ability to use it when you really need it.

One of the key concepts in stealth project management is that the PM quietly establishes a process for doing things that allows you to add a little bit more overt PM over time and no one panics. Remember that 99 percent of the time you will never be given permission to change the culture. On the other hand, subtle changes from within the system are almost always allowed if they produce a positive result.

Have a team-planning meeting to create a shared vision of the project. This vision should include not only the whys and the wherefores of the project but also the way in which the project will be managed. This meeting should be held very early in the project and should be focused on gaining agreement on the following topics:

  • The development approach: In most shops that haven’t made a conscious decision to explore other approaches, all development is based on some form of modified waterfall methodology. The nimble project manager knows that there’s absolutely nothing wrong with using a waterfall method unless it appears that the requirements of the project are either highly nebulous or a lightning rod for a disagreement. In this case, in order to have a successful project, it is critical that the development approach chosen allows for rapid prototyping and extensive user feedback. (One note of caution: Be very careful not to move beyond your own area of competency and/or that of the team. Implementing extreme programming might look like the right approach, but it requires support and commitment from all parties. If support is lacking, you don’t need to introduce a point of failure.)
  • The timeline and other project constraints: Project success is often won or lost on this one point. If you, as the PM, think the important thing is to deliver a product in six months, and the team thinks that the most important thing is delivery x.y.z functionality to the users—with all the bells and whistles intact—then the project is lost before it ever starts. Introducing concepts such as value engineering and stressing the cost/benefit trade-off early on are important. This step can involve some serious negotiation with the project team, especially around the area of technology. New “sexy” technology is what attracts a developer to the project. If the project constraints end up leaving the project looking like it’s nothing more than “routine coding work,” you could have some unhappy campers on the team.

Establish the communications channels
Get agreement that the PM will be notified when a task is complete or falling behind. This is best regarded as the “no surprises” policy, and it’s extremely important to present this from the perspective that, as the PM, you’re there to help get the job done, not to punish. The team members should decide how the updates are delivered, based on their way of working. Voicemail, e-mail or even a note on the PM’s desk would all suffice. The key factor here is that it should be easy and acceptable to the developers, even if it’s a little more work for the PM.

Get agreement on status meetings. In general, developers seem to hate meetings and managers seem to love them. Be flexible and adjust your requirements around the desires of the team.

  • For small teams: Keep formal meetings to a minimum and do a lot of management by walking around—impromptu meetings in the hall or around the coffeepot work as well as anyplace else.
  • For teams with leads: Coordination between teams often takes the team leads being in the same room together—again, defer to the wishes of the leads, but a midweek meeting every week or two usually meets everyone’s needs.

Communicate with stakeholders via an informal kick-off meeting. The purpose of the kick-off meeting is to articulate the project scope, direction, and approach to all the stakeholders. In general, with stealth project management, this meeting should be low key (no off-sites, just a conference room), and the entire agenda should be planned so that the meeting won’t exceed two hours (formal kick-off meetings are usually between four hours and three days). Your goal in this meeting is to introduce yourself to stakeholders and allow them to see that you’re just a little bit different in your approach from other team leads they may have worked with. The secret is to get people to associate your stealth PM activities with your personal style of management.

For every team lead or manager who’s ever complained about working in a crazy, chaotic environment that management refuses to change, stealth project management offers a clear answer. The goal of stealth PM is not to change the company or the behavior of management; the goal is to bring order and structure to your project without offending the cultural sensibilities of your coworkers and project stakeholders.

In order to do this successfully, you must cultivate and use your own internal sense of good project management. In a stealth environment, no one will tell you to identify your high-level risks or to assess your stakeholders and sponsors, or establish your initial area of order. If these activities get done, they get done because you felt they were important enough to do.

What’s your take?

What do you think about stealth project management? Have you tried it? Do you have a question for Donna that she can address in a future article in this series? Post a message in the discussion board below or send us an e-mail.