How do you keep a project on track while working in a CMM (Capability Maturity Model industry-quality standard), level 1 environment? The nature of a level 1 CMM shop means that software development practices and results are inconsistent. On top of that, some company leaders may see formal project management as unnecessary overhead.
In a previous article, the concept of stealth project management was introduced as a way to accomplish enough PM to keep your project on track without violating the accepted norms of the company culture.
In the early planning phases of a project, stealth project management strategies are similar to those used in traditional PM. Once you reach the project's execution phase, stealth project management strategies will differ. One major difference involves the fact that formal project management exists to help and support PMs achieve consistent procedures. In a stealth situation none of that support exists. Each strategy a PM chooses to adopt in a stealth situation is chosen because the PM believes in it and has developed the internal discipline to accomplish the task without additional support.
Here is how to bridge the gap between what a project manager can do under the circumstances and what they should do. These suggestions should be altered based on your company's culture and your personal strengths and weakness as a PM, but they provide a place to start.
In some CMM level 1 companies, projects are launched with no real commitment to delivering a product on time or under budget. The person with the loudest voice and the most political clout sets the priorities. Once a project starts, people just keep plugging away until it is completed or killed by someone frustrated with repeated failures. It may seem strange then to advocate that controlling time is the place to start in a stealth environment, where time seems to be the least constrained variable. But there is a reason why it works.
In a chaotic environment, you need to establish at least a pretense of boundaries. Formal project management postulates the triple constraint (cost, time, scope). But in your typical software development environment, cost is completely transparent and scope can and will change. That leaves only time as the variable that can be fixed.
Controlling time in a stealth environment can be very difficult. Cultures that force PMs to take project management activities under the radar have a negative attitude toward simple best practices, such as tracking project costs using a project number. To avoid getting blindsided in this environment, the stealth project manager has to be very good at perceiving where the project is in terms of work that’s been accomplished, what work remains to be done, and how quickly the current work is progressing, all without resorting to formal tracking tools.
The solution to this problem is to develop an internal global positioning tool. The best tool I’ve found to help develop this internal sense of position on the project is the traditional Gantt chart. In the stealth mode, the project-scheduling package is used as a planning and modeling tool rather than as a control tool. This strategy is fundamentally different from that found in formal project management. Ninety percent of the features available in some of the most common packages will remain unused in this scenario (no baselining, no tracking, no resource leveling, etc.). The feature you’ll need the most is the graphical picture that shows project duration and relationships. That is, if task “e” slips, it will take g, h, l, and m with it.
In order to get maximum benefit out of a project scheduling tool in the stealth environment there are best practices you need to follow:
- Always estimate tasks by duration and not by work.
- Always dependency-link tasks where appropriate.
- Always make sure that the project plan shows a critical path (even if you have to fudge durations and dependencies to get to there).
- Only use the resource assignment feature for critical resources—do not attempt to resource load the project.
- Use the milestone feature to call out all major deliverables (with a “must be done by date” scheduling constraint).
- Keep the schedule simple enough that you can carry it in you head.
- Continuously refine the schedule as required, adding tasks, reordering the work that needs to be done, moving things on and off the critical path.
In formal project management, many of the above statements are absolute and total heresy. But in the stealth environment, they make the difference between having a tool that absolutely helps manage the project and one that simply steals valuable time from the real job of managing the project.
The key element in controlling time in a stealth PM project is to never let a slip occur without figuring out how to bring the schedule back on track. While there may be a thousand and one reasons why a schedule slip has to be accepted, in the end, the iron discipline of always knowing what it would take to get back on track and communicating it to your team and stakeholders is what makes stealth project management effective.
I should warn everyone that this is often the point where stealth project management is thrown out the window. It can be very difficult for project managers to have people stare at them like they’ve lost their minds, especially when the schedule slip has happened early in the project. Very early in my career, when I worked in a number of these organizations, I coined this as the “don’t rock the boat and don’t spill blood on the carpet” syndrome. The rule in these companies is: Don’t escalate anything prior to the point at which it reaches a complete crisis and then, once it has reached a crisis, don’t point fingers or cast blame on the guilty parties. For a project manager to recommend cutting functionality or increasing hours for a short period of time in advance of the situation, and to become critical is counter-cultural craziness.
Handling a schedule slip once it’s happened doesn’t have a one-size-fits-all solution. Sometimes, the right answer is to cut scope unilaterally and beg forgiveness if anyone notices. Other times, you may need to accept the schedule slip and replan the project.
As a PM, it’s very important to understand—when something slips—whether or not it was a one-time event or evidence of a systemic problem. One-time events are easy to accommodate but a systemic problem (uncooperative users, over-committed staff, poor skill mix or competency with the staff you do have) can be much tougher to deal with in the stealth environment. In a formal project management environment, escalating these issues can be relatively easy (though their resolution might still be difficult). In a stealth environment, the only thing you have to rely on is your own ability to gain commitment and support from anyone who might help you.
For practitioners of stealth project management, formal change control procedures are, of course, out of the question, but there are a number of informal change control processes that work extremely well. The first and most effective technique is what I call “Release 2 is your friend”. Instead of saying no, it is easier to tell someone “that would be a great feature…but since our first release is on May 1, we’ll need to hold this until release 2.”
When managing scope using a release 2 approach, consider the following points:
- Keep the enhancement list as visible as possible. One strategy is the use of a project Web site.
- As the project progresses and changes occur, see if any of the release 2 functionalities could make it into release 1. It might only make sense in a few cases, but you build a much tighter relationship and a much higher trust level with your stakeholders by doing this review.
- When the current release is entering alpha or beta test, meet with your stakeholders and review the contents of the release 2 list. Give them a “back of the envelope” estimate as to how many people and how long it would take to implement these requirements and send them out to begin their campaign for approval. Whether or not release 2 is authorized will not impact your future relationships with the stakeholders. By following this approach, you delivered software to them that worked in a timely fashion and you helped them identify their future requirements.
Occasionally, the release 2 approach won’t work and someone who's in a position to make your life miserable if you don’t comply will attempt to strong arm you into expanding scope significantly. If you have a weak project sponsor and find yourself fighting the battle on your own, objectively evaluate the request. After all, the sponsor may be correct and the extra time and cost needed to comply may be warranted.
Evaluate the impact on the project—is it simply additional work (more features) or would it completely invalidate the work to date (changed platform, changed UI)? More work is easy but a hard restart takes a little more thought. In general, always approach a radical change in the scope of the project by officially ending the current project. Wrap up the current project and then kick off the revised project with as many new “markers” as you can, such as new team members, a new project name, etc.
The key concept you are attempting to communicate to your team and your stakeholders is that the change wasn’t a result of poor planning and whim (even if part of it was); the change happened as a strategic response to changing business conditions and the decision to go in another direction is the right one to ensure the success of the new project. If you have a strong sponsor, make sure that she conveys this message at the new kick-off meeting (which might be a little more robust than the first meeting—without violating the low-key stealth requirements). Remember that a CMM level 1 company simply has no structure and no repeatable practices; being level 1 and even having a tendency toward being chaotic doesn’t mean they do everything wrong. A radical redirection in the scope of the project can tear an organization or a team apart or it can be a complete success. No matter how crazy things are, take the time to focus on creating the success.
Most formal risk management methods seem to advocate that generating several pounds of documentation is a way to ward off risk. Since that’s not an option with stealth project management, a PM has to find another way to pinpoint and deal with the risks on the project in an effective manner. The stealth technique that seems to work the best is risk management by continuous observation.
The process is relatively simple and direct. Every time you talk to a member of your team, ask them if there’s anything that’s troubling them about how the project is going. Are things taking longer than they expected? Is something more difficult than they’d planned? In my experience, short of risks that are “acts of nature,” you always get a few hints that something is headed south long before the event itself happens.
Controlling risk on a project requires learning how to listen in the white spaces of what people are saying. On my first large project, I called to get a status on one of the sites we’d recently implemented. The conversation was pleasant and they told me that everything was just fine and not to worry. To this day I don’t know what set off the warning bells, but I caught a plane out to the site the next day, and it took me three weeks to bring things back into line. Formal risk management and formal status reporting never seems to catch this type of situation, so this is one area where a stealth project manager actually has an advantage. When you know it is only your instinct and the instincts of your team members standing between you and disaster, you become hyper-vigilant.
The secret of keeping a project on track in a company that might have to stretch to even reach a CMM level 1, is making the effort to always know where the project is relative to time and scope. It’s the equivalent to developing an internal sense of what the earned value proponents do with their numbers and schedules. Another secret is to fix time as a variable rather than scope. This message has been strongly stated by the advocates of agile development but the advice transcends the method. Fixing time rather than scope works just as well in a waterfall project as it does in an agile project.
Finally, the third secret to keeping a project on track in a stealth environment is to know that something is always going to go wrong with your plans, your timeline, and your project. But if you listen carefully and trust and involve your project team, you’ll be able to fix or work around almost any incipient disaster, and still stay on track.
Stealth project management isn’t the easiest thing in the world to accomplish. It’s not a simplified approach to PM for “dummies” or for “idiots.” What stealth PM does is help PMs complete their projects successfully and ultimately reduce the chaos in the project environment by laying the foundation for the organization to naturally begin to move up the CMM maturity scale.