By Mike Zambruski and Don Cohen
In 2005, I was asked to assume project management responsibilities for an Internet portal project designed to improve relationships between a large company and its customers by giving customers convenient electronic access to company services. Compared with most NASA projects, the work and the resources needed to accomplish it were modest. Technicians, leads, and project managers from ten organizations responsible for design, construction, testing, and implementation contributed a total of fifty-seven staff-months of labor. The scope and relatively short duration of the project—six months—did not, however, save it from uncertainty that verged on chaos. When I was called in, there was no project team in place and the statement of business requirements consisted only of vague ideas and anecdotes, the product of some informal meetings and e-mail exchanges. To further complicate matters, the project had only a high-level promise of funding to cover the anticipated scope and a completion date that could not be postponed.
My first and primary job was to replace vagueness with clarity, to confront the chaos that threatened the success of the project and begin to establish order. I achieved those goals with the help of a simple project management tool that served as an essential part of a deliberative, collaborative process to clarify goals, tasks, resources, and responsibilities.
The tool itself is in Microsoft Excel and therefore readily available to all project participants. It provides a place to define and communicate project phases and tasks, to match tasks with the groups that would be responsible for them, to calculate needed resources of time and money, and to make explicit the assumptions underlying the plans and budgets.
I began development of the tool by defining the key phases of the project, using recommended practices from the Project Management Institute, my book The Business Analyzer & Planner, and prevalent Systems Development Life Cycle protocols. The phases are as follows:
1. Gathering, documenting, and validating business requirements
2. Establishing technical design and system requirements
3. Construction and individual module testing
4. Systems testing
5. Business acceptance and end-to-end testing
6. Production coordination
Phases one and five were then assigned to the business unit; the others were the responsibility of the technology unit. Although this overall work distribution was familiar to the project team, it was complicated by the number of contributing organizations that we had to involve for each phase. Many coordination and negotiation sessions with various technical units were required to coordinate our needs with their existing priorities and arrive at a balance that was equitable but still supported the project scope.
Populating the tool with accurate information was an iterative, collaborative process. Over the course of the first month, several two-hour meetings with the technical leads and project managers were held to clarify the project’s statement of work and build shared commitment to achieving it. Specific task descriptions, responsibilities, and resources were subject to discussion, debate, and revision.
Some version of this discussion process is or should be part of the planning for any project. The tool provided a structured, consistent way for the team to develop successively deeper and more detailed insight into the project scope and confirm the time and labor that would be needed. It makes the project’s requirements, tasks, and expectations clear and definite, replacing the vagueness and uncertainty of conversation with explicit, visible, unambiguous statement. Vagueness about requirements, resources, responsibilities, or schedules is the enemy of project success. The tool helps participants move from a subjective “sense” of what needs to be done to a set of objective statements that can be discussed, debated, modified, and agreed on. The purpose of the tool and a major part of my job as project manager is to replace an “analog” view of the project (a continuous and therefore ambiguous range of values or choices), which can persist for a long time if all you have is discussion, with a “digital” or binary one—a clear either/or choice that shows precisely what is expected and committed to.
In many project management engagements where I use this process and tool, clients are at first impatient about what they see as “a lot of process” (by which they mean “too much process”). Especially when projects are on tight schedules or late getting started—which, of course, describes most of them—the teams that watch the clock tick toward the project deadline as we meet repeatedly to discuss requirements and responsibilities often ask, “Why aren’t we getting down to work?” The answer is that we are doing essential work. Taking time to eliminate misunderstanding about the project and establish commitment to carrying out unambiguous tasks increases the chances of meeting our target date. Once this becomes clear, the complaints about too much process stop. In fact, many of the skeptics have adopted the process and tool for use in their other project work.
Project management is typically done in a cross-functional or matrix environment, so it is no accident that the tool I developed makes it possible to see those connections. In the case of the portal project, it helped all participating disciplines plan and monitor staffing levels, interdependencies, and final deliverables in a closely coordinated fashion. It also enabled us to respond quickly to the ever-changing dynamics of a highly technical environment, and thus helped ensure that the final project was deployed when it was needed at a cost that was acceptable.