tm inside - university of virginiapeople.virginia.edu/~gpk2n/tpm018.pdftm inside the technical...

Volume 1, Number 2 • August 2001 www.elementkjournals.com

U.S. $22.00TM

Inside

The Technical Professional’s Guide to Project Management

In this issue:

Why technicalprojects fail:Avoiding disaster

Project kickoff:Put your coach’scap on and get ready to play ball!

How to be atrailblazer … on paper, that is

Team Dynamics:Your projectcommunicationsplan—far from a game

Why technical projects fail:Avoiding disasterby Glenn P. Kessler

S uccessful project management re-quires a carefully tailored blend of technical understanding, team

building expertise, public relations know-how, political savvy and project man-agement basics mixed with large doses ofoptimism, energy, creativity and persever-ance. Given this broad range of requiredproject management skills, it’s not surpris-ing that many project managers fail todeliver their projects on time, on budgetand with the required functionality. Whatmay be much more surprising is the enor-mity of the odds against success (over 80percent of technical projectefforts fail) and the reasonswhy most technical proj-ects are derailed.

There’s good news,though. The major barriersto success aren’t a mystery.There’s substantial agree-ment on those factors thatmake project managementsuch a risky enterprise. Inthis article, we’ll explorehow six of the most com-mon, and devastating, tech-nical project managementmistakes violate threefundamental project man-agement principles. Byunderstanding how theseprinciples and violations

are related, you can anticipate and headoff problems, beat the odds, and lead suc-cessful technical projects.

Successful project managementTo set the stage, let’s survey the projectmanagement landscape. Figure A givesus a rough picture of the technical projectmanagement landscape. It uses approxi-mate percentages pulled from an often-cited report from The Standish GroupInternational, called “CHAOS.”

Figure A: According to The Standish Group International’s“CHAOS” report, only a small portion of technical projects areeconomically viable.

TPM018.f 5/24/01 2:37 PM

2 Inside Project Management

According to the report, only 16 percent oftechnical projects are fully successful. These fewfully successful projects are delivered on time,within budget and with the full complement ofpromised requirements. A total of 53 percent arechallenged or unsuccessful. Of these, the averagecost overrun was 189 percent. The average timeoverrun was 222 percent. Overall, only 61 percentof their required features were delivered. Theremaining projects were cancelled at some pointin the development cycle.

If technical project starts were distributedevenly across the contiguous United States, and ifa region’s economic stability depended on thesuccess of those projects, 40 states would be indeep economic trouble.

A project leader embarking on a new technicalproject is facing an extremely difficult journey.He’s covering territory littered with the evidenceof past failure. If you’re able to read and interpretthese signs correctly, your chances of making it tothe Promised Land (an on-time, on-budget, fullyfeatured product) will increase. With this infor-mation in mind, here’s an interesting exercise thatyou can try. Make a list of all the projects you’vemanaged over the past few years. Classify themas successful, challenged or impaired (cancelled).Then, run the numbers and compare your per-centages to those in the study we just mentioned.

The basic axiomsSeen against a landscape strewn with project fail-ure, it’s striking that there already exists a substan-tial and very compelling body of knowledge thataddresses both why projects fail and how to preventtheir failure. As noted in another report from TheStandish Group International, called “UnfinishedVoyages,” a much more vexing question, whichwe’ll touch on only by inference, is why, givenwhat we know, projects continue to fail.

To put things in perspective, let’s lay down afew fundamental principles from which the bulkof project management knowledge flows. Theseprinciples share a number of traits with other fun-damental principles, like Euclid’s axioms forgeometry or Peano’s postulates for elementaryarithmetic, for instance. These principles are intu-itively obvious but their consequences aren’t.They’re powerful in their ability to both predictand explain things with which we’re alreadyfamiliar, such as the fact that projects are morelikely to fail than succeed and why. And, theseprinciples can also be viewed in terms of threemain principles: the Context, Entropy and SocietyPrinciples. The specific principle violations weconsider in this article derive from failures to

understand or deal with these very fundamentaltruths about project management. Keeping thesestraightforward principles in mind can go a longway toward avoiding their most debilitating con-sequences.

Caution: Obstacles aheadAny project manager reflecting on his own experi-ence could create a list of the most frequentlyoccurring and devastating project pitfalls he’sencountered. We’ve drawn our list from a numberof sources including published research, seminalarticles and books, shared war stories with col-leagues, a project manager survey conducted forthis article, and first-hand experience. Not surpris-ingly, we’ve found a substantial overlap in ourresults. To better understand this, let’s take a closer look at the three main principles and theirimplications.

Principle 1: The Context PrincipleTechnical projects take place in a broader context. Technical projects seldom take place in isolationfrom the rest of the organization, its customers ora broader environment. If they do, their value islikely to be limited. Most technical projects (andthe most important ones) aren’t just technologyprojects; they’re business projects. Technical proj-ects, no matter how complex and sophisticatedthe technology, are undertaken for business rea-sons. They invariably involve other aspects of theorganization and, in the best cases, the customeras well. A corollary is that successful technicalproject management demands skills that extendway beyond the technology realm. Failure to ade-quately understand and attend to this broadercontext, treating a technical project as a technolo-gy issue, underlies a host of common and devas-tating technical project management pitfalls.Kathy Warden, senior vice president of consultingat Equient, expresses this principle as the need fora “holistic life cycle for managing the project—onewhich considers process, organization and tech-nology change as components of the solution.”

Although it’s fairly obvious, violation of thisprinciple takes first place among reasons whytechnology projects fail.

Violation 1: Lack of adequate user input andinvolvement in the projectThe most frequent and devastating violation ofthe Context Principle is lack of adequate userinput and involvement in the project. Inadequatedownstream participation is a familiar, well-docu-mented project management favorite. It’s unusualto find a project manager who doesn’t, based

TPM018.f 5/24/01 2:37 PM

www.elementkjournals.com 3August 2001

upon personal experience, place it near the top ofthe list.

The principle is simple enough. Those who’lluse a product have a valuable perspective on itsdesign. And the cost of ignoring this perspective isextremely high. In the first place, incorporatingend users early in the process significantly reducestheir natural reluctance to embrace an unusual ornew solution. This tendency, covered extensivelyin the change management literature, can easilytorpedo a complex implementation effort. Ofequal importance, is the fact that errors intro-duced early in a project, such as a mistake in re-quirements, get increasingly more expensive to correct as the project moves forward. In hisbook, “Software Project Survival Guide,” SteveMcConnell observes that an error can cost 50 to200 times as much to correct late in the project thanit costs to correct it early in the project life cycle.McConnell’s observation suggests an equallyimportant consequence of the Context Principle:

Technical project managers are solving userproblems rather than building systems. Thesesolutions need to be honestly and frequently vali-dated by users long before the final product isdelivered. Without iterative validation the projectmanager runs a strong risk of delivering a prod-uct which either:

• Doesn’t satisfy the requirements as understoodby the end user, or

• Satisfies requirements that are no longer validdue to changes in the broader landscape.

What’s the best mechanism for effective down-stream input? There’s extensive literature tochoose from including the discipline known ascontextual design, as discussed in Hugh Beyer‘sand Karen Holtzblatt’s book “Contextual Designand Quality Function Deployment (QFD).”

Violation 2: Lack of sustained executive manage-ment supportThe next violation of the Context Principle runs aclose second to the first. This problem is almostalways catastrophic and is often derived from afundamental, but frequently overlooked, organi-zational parameter that we refer to as Mean Time

Between Reorganizations (MTBR). We’ve found thefollowing rule of thumb to be a particularly usefulconsequence of the Context Principle:

In many organizations the expectation of sus-tained executive support for a complex andlengthy project simply isn’t realistic. This is partic-ularly true in turbulent economic times. Ask your-self whether today’s management is likely to bearound to see the completion of the project. Anyrealistic assessment of project risk has to includethe possibility of a negative answer. Creating small-er well-defined project milestones, in addition tokeeping the project on track, provides a mechanismfor bridging executive level organizational shifts.

Lack of consistent executive support also oftenresults in a reshuffling of organizational priorities.This can mean the outright cancellation of a proj-ect or the reallocation of crucial project resourcessuch as time, funding, personnel and equipmentfrom one project to another.

Remaining aware of organizational changesand acting to ensure that new executive stake-holders are informed of the project’s progress cansubstantially diminish these consequences.

Principle 2: The Entropy PrincipleThe amount of disorder in projects won’t, of itself,decrease with time.As with any isolated system, a project, left toitself, drifts toward chaos. The project manager’stask is to impose (or extract) order in the face ofthis natural tendency. This is the point of well-defined and repeatable project managementprocesses.

There’s now a vast body of knowledge whichdetails the sort of order required for project suc-cess and the specific areas in which it must beimposed. The Capability Maturity Model (CMM),developed by the Software Engineering Institute,is one such example. Though designed mainly tohelp software organizations improve the maturityof their software processes, the CMM offers somegood planning advice for all types of projects.We’ll focus on the six key principles found in leveltwo (repeatables) of the CMM because they mostclosely identify with a big project trouble spot: theestablishment of basic management controls. Tosee how the key processes fit in, take a look at the

Downstream input, in the form ofrequirements validation, must beiterative.

The elapsed time between significantproject milestones shouldn’t exceedthe organization’s MTBR.

TPM018.f 5/24/01 2:37 PM


following brief overview of the five maturity lev-els of the CMM model:

1) Initial: Success is driven mainly by individualefforts since few processes are defined.

2) Repeatable: Processes related to cost, scheduleand functionality are in place. Success is drivenby repetition of processes that worked on past,similar applications.

3) Defined: Management and engineering activi-ties are in place. All projects use an approvedsoftware process tailored to the software beingdeveloped and maintained.

4) Managed: Software process and product quali-ty are looked at qualitatively and managed.

5) Optimizing: Quantitative feedback gathered inlevel four is used to improve existing processesand initiate new ones.

The six key processes that we’re interested infor our purposes are requirements management,software project planning, software project track-ing and oversight, software subcontract manage-ment, software quality assurance, and softwareconfiguration management. By making sure thateach of these tasks is accomplished diligently,your project stands a greater chance of being com-pleted successfully and you’ve also got yourselfan effective remedy to project entropy.

Violation 3: Unclear requirementsThe predominant pitfall in the project entropy cat-egory is our third overall violation. We notedbefore that failures introduced early in the devel-opment cycle are the most costly to correct down-stream. Unclear, incomplete and inaccuraterequirements are three frequent examples of theseearly life cycle errors. However, clear require-ments really aren’t enough. A related, and no lessdebilitating, entropy error is the lack of a well-defined process for managing changes to theserequirements. Without such a process, the proj-ect invariably succumbs to “death by a thousandchanges” frequently taking the form of the fea-ture creep or even scope creep. These amount to an unauthorized (and sometimes unnotic-ed) alteration in the development plan. The re-quirements management Key Process Area inthe CMM model provides a solid framework foravoiding this pitfall.

Violation 4: Lack of proper planning The fourth major violation is probably the mostobvious of all. The most interesting point about

this violation is that it’s not at the top of the list.While project planning (as embodied in theCMM key process areas listed previously) isoften considered the first job of a technical proj-ect manager, it isn’t the reason that technicalprojects frequently jump the track. We need tolook to context rather than entropy for the mostfrequently cited errors.

Of the specific problems related to lack of proj-ect planning unrealistic expectations, in the formof overly aggressive schedules and inadequatebudgets, are cited most frequently. Once again,there’s a wealth of literature in these areas. For agood informal discussion of realistic projectschedules we suggest you see chapter three ofMcConnell’s “Software Project Survival Guide.”

When we think of project management and theways it can fail, items in the Entropy Category areoften the first to come to mind. This is the techni-cal side of project management. This side of proj-ect management deals with formal methods andpractices. While a lack of process is certain deathfor a project, the Context Principle tells us that anexclusive focus on these issues is also sure toresult in failure.

Principle 3: The Society PrincipleTechnical projects are social undertakings.It’s actually quite rare to encounter a project thatdoesn’t require the collaborative effort of a group(or, more frequently, multiple groups) of individ-uals to achieve its defining objectives. Unlikesome social enterprises (e.g., a church or a com-munity service organization) projects have a veryspecific duration and objective. But this doesn’tmake them any less social or any less subject tothe familiar political and interpersonal dynamicscharacteristics of the many dysfunctional organi-zations we’ve all come to know and love.Technical projects are social organizations inmicrocosm.

The Society Principle implies that, along withorganizational agility (the Context Principle) andproject management expertise (the Entropy Prin-ciple), a successful technical project managerrequires appropriate people management skills.This is the management side of technical projectmanagement. Looking at the most common viola-tions in this area clarifies where the developmen-tal emphasis should lie.

Violation 5: Lack of clear vision and objectivesThis violation has both internal and external con-sequences. A precondition for the success of anyteam is that it knows where it’s going. Uncleargoals create a domino effect. Without clear goals

TPM018.f 5/24/01 2:37 PM


both the project management process and teammembers’ roles within that process are leftungrounded. Team members won’t understandwhy they’re being asked to do what the projectmanager requests. The consequence is invariablya divergence among team members about whatthe project is, what the deliverables should looklike, and how they’ll be implemented.

The vision must also make the project’s rela-tionship to the rest of the organization clear.Without an understanding of this broader con-text, the project team feels like it’s working in abox. This invariably undermines team members’motivation. For the same reason, this vision alsoneeds to be understood and embraced by theother members of the organization, in particularthose who have a significant interest in the pro-ject’s success.

It’s a primary responsibility of the project man-ager to ensure that all the interested partiesunderstand the project’s impact and their respon-sibilities in realizing its mission. It’s quite anundertaking, but one that’s well worth the effort.

Violation 6: Inadequate attention given to projectmomentum, harmony and rhythm Finally, the Society Principle highlights the dangerof ignoring or minimizing the social dynamics sur-rounding the project; this is expressed as our lastviolation. For project managers with extensivetechnical training and experience, the softer socialside of project management is often the least famil-iar. While this can make it tempting to ignore, itdoesn’t diminish its importance. This is wheremore general management and leadership skillsfind the most traction. There are three dimensionsto consider: personal, team and collaborative. Theresults of neglecting any of them are familiar, welldocumented and, invariably, undesirable.

• Getting personal. The personal dimension rec-ognizes that project participants are individu-als who need to be recognized for each one’scontributions. If you expect team members toexcel, they need the tools and conditions re-quired to do an excellent job (e.g., appropri-ate software and a quiet space conducive tofocused software development). They need tobe appropriately motivated and need to seehow their participation in the project makes adifference. Team members also need to under-stand why the project is important.

• Teaming with possible pitfalls. The teamdimension recognizes that the project team isn’tsimply the sum of the individuals that com-

prise it. The team is an organic entity withneeds and a rhythm all its own. A project man-ager’s failure to understand the basic stages ofteam development or the normal fluctuationsin project rhythm can seriously hinder a team’sability to sustain the required forward motion.Other major pitfalls in this category includeuncontrolled problem employees and a lack ofthe right blend of skills or experience on theteam. Any project manager would benefit from at least a quick read of “Peopleware,”Tom DeMarco‘s and Timothy Lister’s classicdiscussion of the personal and team dimen-sions of project management.

• Collaborative effort. The collaborative dimen-sion of the Society Principle recognizes that theproject doesn’t end with the project team.Failure to understand, incorporate, continuallyattend to or manage the needs of the keystakeholders in the project will undermine itssuccess. As Kathy Warden says, “Leading theproject team and holding the technical visionfor the project are only portions of the job ofproject manager. Working with the businessstakeholders to ensure the system meets busi-ness needs should be the primary objective.”Seen from the perspective of the SocietyPrinciple, the primary function of a projectmanager is not to deliver a technical productbut to manage and satisfy the commitments tohis constituency. As Peter G.W. Keen puts it,“Successful software development and sys-tems integration require commitment manage-ment, not project management. Companiesshould restart their IT processes around techni-cal and organizational commitments and therelationships between them.”

Summary of the project life cycleviolationsOnly a small percentage of technical projects suc-ceed, meaning they’re completed on time, withinbudget and with all required features. But thecauses of these failures are well understood. Themost common and debilitating project manage-ment errors can be captured under three funda-mental project management principles: Context,Entropy and Society.

The table in Figure B on the next page summa-rizes these violations against a simple project lifecycle model. The chart indicates both the projectstage(s) in which a violation can most effectivelybe addressed and the relative importance ofattending to it in the stage. A filled-in circle (l )

TPM018.f 5/24/01 2:37 PM


indicates that it’s critical to pay significant atten-tion to the violation in that stage, in order for theproject to succeed. A dotted circle (¡ ) indicatesthat appropriate attention to the item in this stagewill substantially increase your chances of suc-cess. An empty circle (¡ ) indicates maintenancemode: Check in frequently to ensure that entropyhasn’t taken over. Note that the close-out stage ofthe project demands attention to all the pitfalls.

Evaluating how these pitfalls were handled in thecourse of the project is an invaluable part of aproject post mortem. As with other areas, experi-ence, good or painful, is frequently the bestteacher for a technical project manager.

Selected references1. Hugh Beyer and Karen Holtzblatt, “Contextual

Design” (Morgan Kaufmann Publishers, 1998)

2. Peter G.W. Keen, “Let’s Put ProjectManagement Out of Its Misery”(Computerworld, 12/7/98)

3. Software Engineering Institute, “The CapabilityMaturity Model” (Addison Wesley, 1997)

4. Steve McConnell, “Software Project SurvivalGuide” (Microsoft Press, 1998)

5. The Standish Group International, “CHAOS”(The Standish Group International, 1995)http://standishgroup.com/visitor/chaos.htm

6. The Standish Report, “Unfinished Voyages”(The Standish Group International, 1996)

7. Tom DeMarco and Timothy Lister, “Peopleware”(Dorset House Publishing, 1979)

Figure B: Project life cycle violations such as these are an all too common occurrence.

Project kickoff: Put your coach’scap on and get ready to play ball!by Nancy Wickmark

P roject kickoff is a lot like a pregame huddle; you want to prepare and psych your team up for success. As a project manager (PM),

you probably find that scheduling the kickoffmeeting and inviting the key players to attend isthe easy part of the process. What may prove to bemore difficult, and what ultimately separates thewinners from the losers on the playing field, be itturf or project site, is the discussion and mood youinspire at this meeting. Why? Because your pres-entation will color the tone of all of your team’scommunications and work efforts for the durationof the project.

This being the case, we think there’s a lot youcan glean about preparing your team for a suc-cessful outcome to your project by putting to usethe finely honed approach that coaches use to gettheir teams ready for the big game. So, now it’stime to put on your coach’s hat and have a littlefun preparing your team for its big game!

Knowing how the game is playedLike football and most other competitive teamsports, projects have conditions to consider andreactions to those conditions that need to becrafted before your team even takes its first

TPM018.f 5/24/01 2:37 PM


step onto the playing field. As the coach (inessence) of your project team, knowing whatthese conditions are and calculating what yourteam’s reaction to them will be is your first realchallenge.

The conditions and goals are pretty much thesame from game to game, project to project.You’re out there to win with dignity by playing bythe rules. But it’s the subtle differences, such asteam morale and business politics, that make thisgame (or this project) different from the rest. Ifyou ignore these differences, no matter how smallthey may be, you run the risk of contributing toyour team’s potential failure. If you choose toaddress them and share what you know withyour players as best you can, you’ll find thatthey’ll perform the best that they can and will bemore likely to succeed with fewer time-, effort-and money-draining errors.

Looking at the lineupIf you’re worth the dirt in your cleats and thegrass stains on your britches, there are some logis-tics, shown in Figure A, which you’ll want to con-sider prior to addressing your team at thepregame huddle. First up is the condition of theplayers. Whether you’re talking about ball playersor project team players, the questions are thesame. Are they well rested, fresh and challenged,or are they coming off of a string of losses? Whoare the star players and who are the weakestlinks? Is the general attitude positive? Is cynicisman emotion to be dealt with?

How about the level of team maturity? Amature team is the dream of any coach or PM, butmost likely you’ll need to build that maturity asyou go along. Question yourself, as a coachwould question. Do you have many new players?Do they interact and communicate well—do theygel? Do they care about each other? Do they reachout as mentors to one another and bring eachother along? Do they pick each other up from afall? Do you have the right mix of skills, person-alities and attitudes?

You also should take into consideration yourteam’s history. What’s your standing in theleague? What’s your track record? Do you havesuccesses to draw from or holes to dig out of? Isthe team floating on the wings of success orscrambling to prove its abilities?

Scoping out the playing fieldThere are other considerations to take into

account in addition to the players on your team,as shown in Figure B. One of the most important

of these is the condition of the field. Where acoach questions if the field is wet, level, pitted,well marked or properly lit, the PM needs to askquestions such as: What’s the operating Cap-ability Maturity Model (CMM) level? Are thereprocesses and procedures? What’s the technicalinfrastructure and the organizational structure,and what tools are available? Is the technologydriving the solution or vice versa? Is the “vision”clear? Are there business opportunities drivingthe schedule? Is the budget predetermined and isit a constraint? And, are the technologies knownor unknown?

You might not have thought about this, but it’simportant. Do you have the support of the crowd?To a coach, the presence of a supportive homecrowd, cheering the team on to success from the sta-dium bleachers, fuels a team’s desire to do well. Forthe PM, it’s the presence and involvement of thestakeholders that fill the role of the crowd. Do you

Figure A: These team logistics need to be addressedbefore the kickoff meeting.

Figure B: It’s a good idea to think about how you measureup in terms of these other project considerations as well.

TPM018.f 5/24/01 2:37 PM


have their support? What does it hinge upon? Arereputations at stake? Is there a strategically placedand long lasting investment in the project? Whatrole do subtle business politics play? What are thedominating expectations of the stakeholders?

Who’s up next? Why, it’s you—the coach/PM.As the leader of this team, are you prepared tocoach? What are your strengths and abilities? Doesyour style and approach bring out the best in yourteam? Are you prepared with the business, techni-cal and interpersonal knowledge that you need tomanage the project effectively? Can you give yourteam it needs to do its best?

And finally, who’ll be around to monitor you?Why, of course, even in project managementthere are referees (Oh! The referees!). PMs need tothink about Software Configuration Management(SCM), Software Quality Assurance (SQA), test-ing, and peer reviews. Should you expect resist-ance to formal project management? Is there asteering committee in place, and if not, shouldthere be? And unfortunately, if the stakeholdersare running multiple projects at once, is there biasfor one team over the other?

Let’s talk strategyOnce you’ve gone over the above-mentionedfactors in relation to your project, you can

develop a strategy that will take advantage ofany favorable conditions that you’ve comeacross. While you’re at it, you might want toprepare mitigation plans for those areas whereconditions aren’t favorable.

Here’s an example. If your team is a “handme down” lot, bearing only slight resemblanceto the skill sets needed, you’ll want to compli-ment them on their strengths and present a planof action that will build the skill base required.Steps you can take to build your team’s skillbase include providing training, mentoring, jobsharing and peer reviews. Another step youmight want to take is to have your team partic-ipate in a team building exercise where every-one has a chance to address the group. This willhelp you establish an expectation for open com-munication between team members, right offthe bat. This open communication policy shouldalso include you. But don’t worry, you’re notexpected to know all the answers all of the time,just how to get them as the need arises.

To help you organize your thoughts in pre-paration for your own kickoff, we’ve puttogether a kickoff strategy To Do list, shown inFigure C, that’s made up of components wethink are important parts of any successful kick-off strategy.

Psych them up, coach!The correlation between the project kickoff andthe pregame huddle provides us with a greatopportunity to put into practice the winning waysof those masters of pregame planning—coaches.

Do as they do. Before you address your team,take the time to sort out the logistics, developyour strategy, and finalize your game plan. Yourproject team is counting on you to lead them tosuccess. Follow the lead of the zealous peeweecoach and you’ll feel good about the job you didfor the team members before they even knewthey were a team. Get them ready for the game,compliment them on their strengths, and givethem what they need to prove they are winners.Psych them up, coach!

Figure C: This To Do list keeps your kickoff objectives in focus.

Free tips to your inbox!Check out www.elementktips.com and sign up to receive super software tips emailed to your inbox every week. Written by the samegreat Element K Journals editors whose articles you read each month, these quick tips can’t be beat to make you a software expert!

TPM018.f 5/24/01 2:37 PM


How to be a trailblazer … on paper, that isThe what, when and how of good project documentation

by Jeff Bankston

A ny good project manager will tell you how important creating and using docu-mentation is toward having a successful

project delivery. But how many have ever reallythought about why this is the case? In this article,we’ll review the types of documents you shouldbe creating and maintaining along the project lifecycle in order to ensure good project documenta-tion is being kept. We’ll also go over some of themore important reasons why good project docu-mentation is such a must by stepping through ahypothetical project where the project managerand client value proper documentation. So packup your project plan and prepare to blaze a trail toproject delivery success.

The great paper trailAll projects make use of a variety of documentsduring their tenure. At each major stage of theproject life cycle, there are specific documents thatthe project manager needs to create and/orupdate in order to ensure proper documentationof the project activities and expenditures. In thissection of the article, we’ll introduce you to someof the most important and widely used docu-ments in the field of project management.

The SOW, our project compassOf all these documents, the Statement of Work(SOW), shown in Figures A through C, is theguiding light for the entire project. This is a staticdocument in and of itself, because both the con-sultant and customer must agree to the goals ofthe project that are indicated on the SOW. Onceyou’ve created the SOW, you’ll likely find theneed to make use of some standard life cycle proj-ect documents, especially if along the course ofthe project you find that you need to amend theSOW in any way.

The path of the project life cycle, in printLife cycle documents are normally dynamic, liv-ing entities that are subject to change without

Figure A: The SOW is the guiding light for the entireproject.

Figure B: Providing an overview of project expectations,the SOW is helpful for both the PM and the stakeholder.

Figure C: The SOW must be signed off on before theproject commences.

TPM018.f 5/24/01 2:37 PM


notice. Cumulatively, they leave you with a thor-ough paper trail of the project’s problems andprogress as you work to achieve the goals laid outin the SOW. Individually, they serve different pur-poses, as you’ll see.

When you need to make amendments to theSOW, the Change Control Form is the one you’lluse. As shown in Figure D, it requires the signa-ture of both the customer and the project manag-er. Both signatures are required because thechange may ultimately influence the time line andoutcome of the project.

The Project Plan is a document that consultantsadjust on a weekly basis (sometimes on a dailybasis) as the project evolves. This is because theproject plan is a dynamic record of the staffing,scheduling and budgeting of the work activitiesthat need to be accomplished for the project to becompleted; so as the project progresses, the projectplan does also. It’s sometimes created when the

SOW is signed, but it’s usually created once thework starts. Our project plans are typically createdusing Microsoft Project 98 or 2000, depending onhow our documentation needs to integrate withthe customer’s software; this is another importantpoint to keep in mind. But, there are several othergood project software tools besides MicrosoftProject to choose from.

Long-term projects tend to have milestonereviews in which all parties discuss issues impactingthe work on the project to date. This meeting usual-ly results in a signed document, called the ProjectReview. The signed Project Review is important; it’stangible evidence that specific hours of work werecompleted to the customer’s satisfaction and thatthe customer has agreed to pay the bill for servicesrendered up to that point in the project. As a matterof course, it’s not unusual at all for the ProjectReview meeting to end with a discussion of thework to come.

Another group of documents that is essential tomaintaining good project documentation is theProject Recommendation Report, shown in Figures Ethrough G. In general, these are static documentsthat detail events, conditions or recommendationsto events or conditions that could affect the project.

Next, we have the Status Report. This report canbe generated daily, weekly or as a single file that’skept up-to-date and is used as a running report ofproject events for the life of the project.

Last, but not least, we have the Final Report.This report is usually framed early in the projectbecause in terms of content and flow, it details the

Figure D: The Change Control Form is used for recordingand approving changes to the SOW.

Figure E: The Project Recommendations Report custom-arily includes a title page listing the parties involved andthe date of submission.

Figure F: The purpose of the Project RecommendationReport is to detail events, conditions or recommendationsfor events or conditions that could affect the project.

TPM018.f 5/24/01 2:37 PM


actions taken and issues resolved that were out-lined in the SOW, which you’ll remember is thefirst document you’ll create at the start of yourproject. The Final Report is the final proof that theproject was completed according to the specifica-tions outlined in the SOW. You can measure yourcurrent project documentation list against our listof document must-haves.

1. Statement of Work. The master guide for theproject. This is the first and most importantdocument to have.

2. Change Control Form. This document is usedto make amendments to the original SOW andrequires the signature of both the customer andthe project manager

3. Project Review. Long-term projects tend tohave milestone reviews in which all parties dis-cuss project issues to date. This meeting usuallyresults in a signed document acknowledgingprogress and completion of services renderedup to a specific point in the project plan. Someconsultants use this document to invoice thecustomer at specific intervals during the project.

4. Project Recommendation Report. This is agroup of static documents that details recom-mendations for project events or conditions.

5. Status Report. This can be a daily or weeklygenerated report or a single file kept as a run-ning record of events during the life of theproject.

6. Final Report. A static document, usuallyframed early in the project, that details actionstaken and issues solved that were outlined inthe SOW. This report is the final proof that theproject was completed according to the specifi-cations outlined by the project manager andthe customer in the SOW.

When to use what—mapping it outWhile every project has its own unique nuances,the documents that project managers need to usein order to maintain good project records are pret-ty universal. In the following section, we’ll detailthe use of these documents as they’d be employedby a project manager during the course of a three-month-long database design project for a fictionalcompany, Corporation X.

At the foot of the hillLet’s say that our three-month-long databasedesign project has been just approved by our fic-

tional company, Corporation X. Now it’s time tostart our project. The SOW says that Corporation Xwants their existing Oracle 8 database that containstheir customer shipping information integratedinto a private Web site. They’ve used Oracle since itwas just a fledgling database, yet they’d neverthought of using it on the Internet—until now.

Corporation X provides shipping and receiv-ing facilities for dozens of businesses and theygenerate weekly paper reports for each of thecorporation’s customers. These reports let eachcustomer know how much of what product is instorage, when products on hand fall below speci-fied levels, and the dollar value of the total storedinventory. (This is important for insurance rea-sons, so the amount of product on site must beprecisely accounted for to prevent excess inven-tory from being wasted on site.)

This new Web site our corporation wants to putup is designed to allow existing companyemployees to continue updating database infor-mation, while also allowing new and existing cus-tomers access (via the Internet) to this database.The goal is to eliminate the weekly paper reports,reduce excess overhead, and speed up the time ittakes to deliver the product to the end site.

Setting up our Web siteOnce we’ve established the business goals thatmust be solved by the Web site from reviewing theSOW, we need to create a project plan. In our proj-ect plan, we must set milestones so that we haveconcrete dates for completion of the tasks thatmake up the project. How do we do this? First,

Figure G: Both the consultant and the customer signoff on the Project Recommendation Report.

TPM018.f 5/24/01 2:37 PM


we’ll need to make an outline of the tasks we’llperform in setting up the Web site server. Thesetasks include how we plan to create the connec-tions between the Web site and the database, andthen also how we’ll set up Web site and databasesecurity controls for the users.

Exploring, testing and recording thedoings at our Web siteNow that we’ve done the setup work, it’s time totest it all out to make sure it works the way weintended. This amount of work is likely to take usabout a week or two to accomplish, so this task is agood candidate for inclusion in our weekly statusreport. The testing of our connectivity work on theWeb site presents yet another opportunity for us tomake use of our newly acquired documentationskills. Here we’ll need to create some form of proj-ect recommendation report that details the stepswe’ll need to take in order to accomplish the test.This is also the point at which we may need todraw up a change control form. If, for instance,Corporation X decides to release more informationto its customers via the database, we’ll need to doc-ument their request, in particular because a changelike this would indeed impact and alter the SOW.In this case, the change control form needs to besigned by both our project manager and the projectpoint person from Corporation X. Taking thesesteps keeps us covered for the extra time andexpenditure we’ll incur working on the change.Once the paperwork is out of the way, we can makethe changes and get back to testing.

Meeting at base campLook how far we’ve come! At our project reviewwe discussed which milestones we’ve completedand which ones we’ve yet to reach. For the mostpart, Corporation X was happy with our progress,but toward the end of the meeting, they broacheda subject that we thought had been put to rest.

X marks the spotThe subject that Corporation X felt needed more dis-cussing revolved around an incident that occurredearlier in our project time line. What had happenedwas that when our designers tested the new Oracleapplication independent of the Web site, it ran fine.However, when the custom Oracle application wasinstalled on the Web site, even though it was cor-rectly written, the application used the wrongODBC drivers and this resulted in not only thewrong data being returned to the Web site user, butin the system’s security being compromised as well.This upset Corporation X and rightly so. They were

concerned that this sort of problem would creep upagain if we kept the site design as it was.

Our coordinates line up properlyWe told them that we’d solved the problem andtheir system was fine, but they still had concerns.Lucky for us, we’d kept good, detailed documen-tation of all the events and conditions that hadcome up on the project so far. One document, atest recommendation report signed-off on byCorporation X prior to the application installa-tion, proved to the Corporation X team that we’daddressed the problem, just like we’d said. As youcan imagine, without creating and maintainingthe proper and accurate documentation, this typeof dispute is very difficult to solve.

Upon reaching the summitLet’s presume that this project has evolved prettymuch as planned and where it strayed, we madechanges using the proper channels. Now, ourastute project manager needs to prepare the finalreport, which he’s actually been compiling sincethe Web site project began. How could he do this,you ask? Well he’s found that in 90 percent of theprojects he’s either managed or evaluated fordeployment to a customer, the outline for his finalreport could be extracted directly from the SOW.Sure, he knows that changes are inevitable, but thebackbone of the report can be thus outlined. Assuch, with a little technical writing expertiseapplied, any project manager can be filling in thefinal report’s draft form as the project itself evolves.

Working on the final report this way has twoprimary benefits for the project manager. Numberone, it reduces the time needed to complete thefinal report; and number two, it helps compensatefor any loss of brain cells due to overwork thatmay impair your ability to recall the details ofeach part of the final report.

Think of the draft final report as a book outline.It has major sections (which should directly mapto SOW objectives), minor objectives (whichshould map to the project plan milestones), andsupporting documents, like the test plan results,(which clearly show that the Web site passedacceptance testing).

Packing up and heading outGranted, this may only be the basic Web site anddatabase connectivity, but it’s completed and inoperation. This is a major accomplishment, andshould be well documented so that each groupinvolved in the project knows when these mile-stones have been reached.

TPM018.f 5/24/01 2:37 PM

Team Dynamics


It’s only naturalGetting paid is nice; avoiding harmful and dis-tasteful disagreements is useful; but there’s a muchmore important reason for producing accurate andconcise paperwork: so you can pick up where youleft off when you come back to work for this cus-tomer in the future. And, if you’ve done a good job,it’s only natural to assume you will.

Yes, indeed, we’ve all come in contact with theage-old problem of facing a new project at a formerproject site and saying to ourselves, “Now whatdid we mean when XYZ was done?” Talk abouttime-consuming. But now, if you were to startmaintaining good, thorough paperwork on proj-ects as you went, you’d find that you’d spend lesstime on guesswork and more time on actual projectwork. Sure, it’s true, we know, setting traces anddebugs would help get us up-to-speed if we didn’thave all the necessary paperwork, but do we reallyhave the time to do this?

Back to the site: Plotting our new coursewith the help of earlier paperworkSuppose Corporation X wants the Oracle databaseextended to allow third-party customers limitedaccess to the same data, but in read-only mode?The problem is, the database tables were alteredby the customer’s own people since we lastworked on the site, so our previous work isn’t inthe same format as it was before.

How can we get started on the short three-dayproject without spending five days getting reac-quainted with the code? Our previous documen-

tation, both written and in the code, would bequite the lifesaver here. Why? Well, when we cancome back to this same customer, spend next tono time in the organizational aspect of the newproject, and turn out the same high quality proj-ect as before (thanks in part to our “notes”—ourpast project documentation) our customer willappreciate us more and will most likely invite usback for additional projects as well.

Navigating and managing yourproject documentationIt used to be that project documentation was allkept together in a series of labeled binders thatcould be found in the project manager’s office.Nowadays, though, binder-bound printouts arestill a common enough sight, internal and privateWeb sites have become a more pervasive methodof sharing and delivering project informationbetween the parties involved. Flexible enough tobe updated even from the most remote location,and easy enough for anyone to create, Web siteshelp coordinate and deliver documentation toeveryone involved in the project in a timely andefficient manner. Whether you opt for the binder,the computer or even some amalgamation ofboth, the bottom line here is to be sure you havethe documentation. If you do, you’ll find that theproject trail you’re on is paved with more thangood intentions; it’s lined with ironclad, fact-backing gold. To access the sample documentsincluded in this article, visit our FTP site atftp.elementkjournals.com/tpm/200108.zip.

Your project communications plan—far from a gameby Nancy Wickmark

H ave you ever played the whisper game? It’s the one where one person starts a tale by whispering in another’s ear; the

listener then whispers to another, who whispersto another, and so on. Have you witnessed yourcarefully worded tale deteriorate before your earsas each well-intended link in the pass-it-on chainreiterates her rendition of the “facts?” Eventually

the resulting tale has little or no resemblance tothe original. How about a good game ofPictionary™ where cryptic figures are franticlysprawled on a flip chart while others rush to graspthe meaning without a word being spoken? Thesecommunication games provide challenge andenjoyment in a social setting but when it comes toproject management they’re exactly the games we

TPM018.f 5/24/01 2:37 PM


strive to avoid! In this article, we’ll show you howa good communications plan can keep you fromfeeling like you’re playing the whisper game.

In good companyProject communications have to be taken serious-ly and they need to be planned just as you planthe project’s scope, approach, budgets and sched-ules. As in all of these areas of planning, the suc-cess of your project is heavily dependent on yourability to pull foresight and experience into yourplan. You go to great lengths to make sure it’scomprehensive and relevant to your project.However, the best budget, schedule and scopestatement are inadequate if not appropriatelycommunicated during execution. Because of this,communication plans need to go hand-in-handwith all of your other plans.

First, you need to believeWhy plan for communications? We often blame alack of resources, or scope creep, or unexpectedevents for missed project deliverables and over-run budgets. It’s pretty safe to say that if you tooka close look at the reasons (i.e., if you did someroot cause analysis), you’d find that miscommuni-cation at some point along the way sparked theproblem. Just ask yourself: How many hours arespent correcting misconceptions, missed expecta-tions, under-delivered functionality, rework orrekindling team morale? How many of thesehours could have been avoided if communica-tions were effective the first time around? Everyhour spent on corrections or in a reactive modepulls away hours earmarked for productive work.In addition, consider the erosion caused to man-agement confidence and customer satisfaction. So,why plan for communications? Because you can’tafford not to. In this age of Web development withshort, aggressive schedules, heightened customerexpectations and loosely coupled third-party rela-

tionships there’s no room for rework or customerdissatisfaction.

Then, you’ve got to be proactivePreparing a sound communications plan is a proac-tive effort that ensures quality throughout the lifeof your project. By taking one step at a time you’llbe able to sort through the complexities of yourparticular project, as suggested by Figure A, and fitall the pieces together to create a workable plan.

Next, get to workComing up with a comprehensive communica-tions plan doesn’t have to be a big chore. To helpyou get started, we’ve come up with a five-stepcommunications planning process that makescommunication planning straightforward andprovides you with a comprehensive plan whenyou’re done.

Step 1: Who needs to be in the know?Define your stakeholders. A good communica-tions plan identifies all of the individuals that playa role during the orchestration of your projectfrom start to finish. All of the names of the indi-viduals involved in the project may not be knownduring the planning stage, but a placeholdershould be included to indicate future involve-ment. You should try to keep your informationsimple and include qualifiers such as relationship(business, technical, end user, third-party, etc.),organization(s) (which ones are represented), rolesand responsibilities (at a high level), and contactinformation (phone, fax, cell phone, email, mailingaddress) for each stakeholder. We suggest youstore all of your stakeholder information in aneasy-to-read table format created in an applicationsuch as Microsoft Excel.

Step 2: What do you need to share and when?Identify communication points (in content andtime). A typical shortcoming of most projects isthat the scope of communications is limited to sta-tus reports and formal documents (requirements,design, test plans, schedules, etc.). These commu-nication points are important, but expand yourthinking to include less obvious project controllerssuch as acceptance criteria, project repositories,procedures, task work breakdowns, commonterms, exception or problem reporting, and con-figuration management components. Once you’vecreated a list of all the communication points,assign attributes to each point to give it definition.Some universal attributes are listed in Figure B,

Figure A: You can benefit from fitting all the piecestogether to create a workable communications plan.

TPM018.f 5/24/01 2:37 PM

TM

Inside

www.elementkjournals.com

Inside Project Management (ISSN 1534-4002) is published monthly by Element KJournals, a division of Element K Press, 500 Canal View Boulevard, Rochester,N.Y., 14623.

Customer Relations

U.S. toll free ................................................................................(800) 223-8720Outside of the U.S. ....................................................................(716) 240-7301Customer Relations fax ..............................................................(716) 214-2386

For subscriptions, fulfillment questions, and requests for group subscriptions,address your letters to

Element K Journals Customer Relations500 Canal View BoulevardRochester, NY 14623

Or contact Customer Relations via Internet email at [email protected].

Editorial

Editor ....................................................................................Tricia Campbell

Editorial Director ...................................................................... Michelle RogersManaging Editor .......................................................................... Craig WatkinsCopy Editors ........................................................................ Teena Fortenbaugh

Christine HuntLeesa Israel

Contributing Editors..........................................................................Jeff BankstonGlenn P. KesslerNancy Wickmark

Graphic Designer .................................................................... Melissa Ribaudo

You may address tips, special requests, and other correspondence to

The Editor, Inside Project Management500 Canal View BoulevardRochester, NY 14623

Editorial Department fax ............................................................(716) 272-0064

Or contact us via Internet email at [email protected].

Sorry, but due to the volume of mail we receive, we can’t always promise a reply,although we do read every letter.

Element K Journals

General Manager ...................................................................... Doreen BierylaManager of Customer Relations ...................................................... Nicole PateManager of Operations ...................................................... Elizabeth SherwoodManager of Graphic Design .................................................... Ian CasperssonManager of Product Marketing .................................................. Brian CardonaProduct Marketing Manager ..........................................................Robin Mullins

Postmaster

Postmaster: Send address changes to

Inside Project ManagementP.O. Box 92880Rochester, NY 14692

Copyright

© 2001 Element K Content LLC. All rights reserved. Reproduction in whole orin part in any form or medium without express written permission of ElementK Content LLC is prohibited. Element K is a service mark of Element K LLC.Inside Project Management is an independently produced publication ofElement K Journals. Element K Journals reserves the right, with respect tosubmissions, to revise, republish and authorize its readers to use the tips sub-mitted for personal and commercial use. For reprint information, please con-tact Copyright Clearing Center, (978) 750-8400.

All product names or services identified throughout this journal are trademarks orregistered trademarks of their respective companies.

Printed in the U.S.A.

Price

Domestic ..............................................................................$247/yr.($22 each)Outside U.S. ..........................................................................$267/yr.($24 each)

Our Canadian GST# is R140496720. The CPM # is 1912313.The QST# is 1018491237.

Element K Journals publishes a full range of journals designed to helpyou work more efficiently with your software.To see a list of our products,visit our Web site at www.elementkjournals.com.

but you should come up with others that are relevant to your particularproject communications.

When thinking about timing the delivery of project-related informationto your stakeholders, consider project milestones and customer expecta-tions as drivers. Project kickoff, which we cover in-depth in the accompa-nying article “Project kickoff: Put your coach’s cap on and get ready to playball!” is your first real opportunity to get the word out and open the floorfor suggestions and comments. Following up afterward with some sort ofregular, on-going communication benefits not only your team but the clientas well; just be sure to tailor your message content to the needs and expec-tations of your audience, as previously mentioned.

When thinking about where to deliver your message, consider existingprocedures, available venues and outlets, and the physical structure ofyour team in order to arrive at a decision that will enable you to reach themost people (and the most important people) in the most efficient andeffective way.

Step 3: How should you communicate your message?Customize for effectiveness. Every person on your stakeholder list couldbe operating under a different culture of communications. In order forcommunications to be effective you need to recognize those cultural pref-erences and mitigate them. It isn’t practical, of course, to tailor your com-munications for eachindividual or office,but it’s valuable tooptimize the effective-ness of your commu-nications with the pri-mary stakeholders bycatering to their style.It’s also a good idea to

About our contributorsJeff Bankston is the director of network engineering at BCI Associates, a systems inte-gration firm where he designs and integrates networks of all sizes. He’s also a CiscoAVVID certified network designer. Jeff can be reached at [email protected].

Glenn P. Kessler is a founding partner of Strategic Technology Partners with 20 years ofexperience as an information technology, strategy and project management consultant. Hereports that he’s made all of the mistakes (as well as many others) that he’s written aboutin his article, “Why technical projects fail: Avoiding disaster,” and he’s learned from his ex-periences. Glenn can be contacted via email at [email protected].

Nancy Wickmark is a managing consultant with Spherion Technology Architects. She hasover 25 years of IT experience; eight in development and 17 in management. Her passionsrevolve around building personal/team relationships for the purpose of productivity.Communications and organization are two of her favorite management tools. Nancy has abachelor of science degree in mathematics and a master’s degree in managing informationsystems. She’s also a certified facilitator for the Gartner Core Capabilities and eBusinessproject management courses. Nancy can be contacted at [email protected].

Figure B: Thesecommunication points

will help you hone inon the best message

for each audience.

TPM018.f 5/24/01 2:37 PM

Please include account number from label with any correspondence.

Inside Project Managment

Coming up...• Recovering from project failure

• Better team communication via your Web site

• Keeping the lines of communication open with status meetings

2013

16

identify those individuals who play a key role in deci-sion-making and make sure that you’re getting theirattention too.

To do a good job of custom fitting communicationsto the message recipient, you need to do your home-work. For starters, you can ask each of the key playerswhat specific types of project information they’d like tobe kept apprised of. You should also check with themto see how they’d like to receive the information (meet-ings, phone conferences, Web site updates, etc.) Next,marry all that they’ve told you to the resources youhave at your disposal. In creating your overall commu-nications plan, don’t forget to take into considerationcultural differences, language barriers and time zonedifferences as well! These can be real “gotchas” if youhaven’t taken them into account from the beginning.

Knowing what’s appropriate for your target audi-ence will help you define your communications so thatthey’re effective and efficient. The preparation anddelivery of communications shouldn’t be a drain onproject resources. When deciding on the options youhave for delivering your communications, be a littlecreative. Ingenuity may serve you well when it comesto preparing information for a varied audience.Consider using forms or templates that identify theareas that pertain to various stakeholders. Utilize thepower of tools like the Tracking option in MicrosoftWord or the book and tab feature of Microsoft Excel tohelp organize and present information. There are cau-tions with email, but it can make your communicationstremendously efficient if used with some forethought.Use of the Web as a project bulletin board offers attrac-tive global, around-the-clock access that might be justwhat you need to keep a busy executive in the loop.

Step 4: Where should you communicateyour message?Pull it all together. Now that you have the who, what,when and how of your communications plan answered,you’ll need to pull it all together and decide where toput it so that the people who need to access it can doso with little trouble.

We mentioned at the beginning of this article that thecommunications plan works hand-in-hand with thescope, approach, schedule and budget, so that’s where it

should be documented, right alongside of these otherplans. Whether your project and communications plansare kept online at a project Web site or distributed as partof a mailing or handout, that’s up to you. (If your com-munications plan is significant in size, at the very least,make reference to a separate communications plan docu-ment in your primary project plan document.) By includ-ing your communications plan with the overall projectplan, your stakeholders will have a handy referenceguide at their fingertips for knowing how, when, whereand who to go to for project information updates.

Step 5: Welcome stakeholder feedback and supportGet buy-in. Once you have your communications plandocumented and distributed to your stakeholders, yourlast effort is to get buy-in. By approving the communi-cations plan each stakeholder declares accountabilityfor the success of the project. Without your stakehold-ers’ understanding and acceptance of the strategy andapproach you’re taking with communications, youwon’t get the results you’ve so carefully planned.Present the plan as a draft and let them know that youwelcome their feedback on its contents. Work out thefinal details together. Once you’ve agreed on the finalcommunications plan, publish it as a living documentand redistribute it to all of your stakeholders. You canthen revisit your communications plan throughout theproject, using it as a guide, to make sure you’re still ontarget. Also, don’t be afraid to make mid-course correc-tions to the plan as warranted. As long as you keep yourstakeholders apprised of the changes and why you’vemade them, you’ll be all set.

So there you go!Communication games are great; we love a good gameof Balderdash™ or Cranium™ just as much as the nextperson, but when it comes to communicating vitalinformation about a project to our stakeholders, we pre-fer to take a much different approach. Using the five-step process we’ve outlined above for putting togethera successful project communications plan at the start ofyour project will save you time, frustration, and, whoknows, it may also leave you enough time to fit in agame of Pictionary™ somewhere along the way!

TPM018.f 5/24/01 2:37 PM

tm inside - university of virginiapeople.virginia.edu/~gpk2n/tpm018.pdftm inside the technical...

Documents