Highly complex projects require a multitude of technical skills, and when a team comes from the same background and geographic location, it's easy to take communication skills for granted. However, stakeholders may come from the same culture and still speak very different languages. Human beings are probably the least controllable part of any project, and scope definition can become especially problematic if management, technical staff and customers use different technical lingo.
Through accurate scope definition and clear understanding, all stakeholders can work together to ensure delivery of the right deliverable.
THROWING PEOPLE AT THE PROBLEM …
“Adding manpower to a late software project only makes it later.” This tenet is so accepted that it's called Brooks’ Law, after Fred Brooks, author of the classic The Mythical Man-Month and a manager on IBM's OS/360 project. In fact, Brooks’ Law has even been stated mathematically: The expected advantage from splitting development work among N programmers is O(N) (i.e., proportional to N), but the complexity and communications cost associated with coordinating and merging their work is O(N2) (i.e., proportional to the square of N).
Though there have been IT projects that are exceptions to Brooks’ Law, no manager should count on administering one of those exceptions. In small or large IT projects, something always happens. Using commercial-off-the-shelf products, for instance, frequently means dealing with product incompatibilities and version management of erratically evolving software. At the start, IT project managers should have budgeted money and, above all, time in reserve since it's so hard to recover from an overrun.
Project managers should plan communications strategies by addressing the project at hand and identifying its specific goals and risks. To start identifying those specifics, of course, all stakeholders must know they're talking about the same things. Derek Belyea, associate at GNA Consulting Group Ltd., Vancouver, British Columbia, Canada, and co-chair of the Project Management Institute's Information Systems Specific Interest Group, advises building a glossary of terms that becomes attached to key documents and provides the project's agreed meanings. According to Belyea, IT work groups often tend to evolve their own language. “It sounds like English, but in fact may be a different language,” he says. “The best strategy is to force this process into the open.”
Many Voices, One Definition
Approaches to communications planning vary based upon a project's needs, complexities and size. “The communications challenge is almost always underestimated and it grows exponentially with the project's size,” Belyea points out. Thus, formal communications activities, for instance, will obviously take on far more significance in a large enterprise project in which multiple groups of programmers must cooperate as part of a global team than in an IT initiative with a more limited focus and a smaller group of players. Similarly, a large enterprise project—especially one whose final product will be the IT services the software furnishes, rather than simply being a software deliverable—is more likely than a smaller IT initiative to have multiple organizational entities responsible for its outcome.
Unfortunately, political reality often means that a large IT project's manager must contend with all organizational entities, each of which may on any given day act as the customer and demand non-integral features. “Individuals and teams forcing their own desires on others is very common,” says Scott Watters, director of Software Engineering/IT at Pemstar Pacific Consultants. “Almost every IT project that I've worked on has had these issues.”
Technical staff may be weighing in with proposals that somehow have escaped being verified as actual user needs. After all, if programmers slavishly allowed users’ needs to determine everything, that would remove all creativity from a project. Programmers would be unable to produce those technically “cool” features, which unfortunately often result in the wrong deliverables. “While these flourishes keep the techies excited,” says Belyea, “they add complexity and risk to project outcomes and significant cost to subsequent maintenance. Moreover, they increase the burden on new users, adding to the risk that the project will fail if users refuse to use the product or can't figure it out.”
It can become extremely difficult for a project manager to remain focused on identifying the project's end users and their needs. Indeed, the evidence indicates that many IT project managers are failing to prevent fatal scope creep setting in before their projects are even under way.
Richard Walz, PMP, vice-president of Infotech Management Inc., Arlington, Texas, USA, says that some project teams manage clients to the point of producing a deliverable that doesn't align with the original specification but does deliver on what they really need. However, he feels that simply manipulating clients is unsatisfactory. What's the best strategy for efficient project delivery? “We need to collaborate with our project partners— that's what our clients are—to assure profitable, timely completion of projects,” he says.
The surest communications strategy involves dialogue between a professional facilitator, representatives of the end-user group and the organizational funding entity. Almost certainly, these groups will be closely aligned in their requirements and can agree regarding a baseline. While Watters agrees that a facilitator might be helpful, he sees it as unlikely in anything except a Fortune 500-size situation. “If the IT director doesn't have the authority or backbone,” Watters says, “generally the management layer will end up making those calls.”
If proposed requirements are controversial, repercussions from their implementation must be examined because the requirements baseline will provide the foundation for all ensuing discussions. The project manager should arrange a meeting attended by representatives of all customer organizations in order to baseline the project's requirements documentation. A professional facilitator may conduct the requirements review or a business analyst may work one-on-one with representatives. Senior project technical personnel should be on hand to answer questions succinctly. Simultaneously, in case a customer statement strikes one of the senior programmers as so “stupid” that he or she responds emotionally, the project manager should establish that technical personnel don't have the final say.
The meetings’ primary purpose is to establish those requirements on which all customers agree, so if conflict does occur and isn't quickly resolved, all parties should move on. At the conclusion, successes should be emphasized and the next meeting's work minimized by stressing how few requirements remain in question. Using objectionable requirements, a matrix should be developed. The team can identify the pros and cons of each; cost and impact on end users should be pinned down.
If at the next meeting all customers cannot agree to all requirements, the project manager will have to guide matters to a resolution. Obviously, the end users should be considered first. The requirements document should then be signed by all those in agreement with it.
Ultimately, Belyea says, the objective is “clear, concise and regular communications.” This means providing reports on whether or not key milestones have been met, progress reports on cost vs. budget, regular forecasts of the expected completion date and regularly updated business analyses that prove the project will still deliver business value when completed. PM
Mark Williams is a contributing editor at Red Herring magazine, and has written about business and technology for Forbes SIP and Wired.
PM NETWORK | DECEMBER 2001 46 | www.pmi.org