Tải bản đầy đủ (.pdf) (671 trang)

OReilly the art of project management apr 2005 ISBN 0596007868

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (4.05 MB, 671 trang )

TheArtofProjectManagement
ByScottBerkun
...............................................
Publisher:O'Reilly
PubDate:April2005
ISBN:0-596-00786-8
Pages:392

TableofContents|Index

"'TheArtofProjectManagement'coversitall--frompracticalmethodsformakingsure
workgetsdonerightandontime,tothemindsetthatcanmakeyouagreatleader
motivatingyourteamtodotheirbest.Readingthiswaslikereadingtheblueprintforhow
thebestprojectsaremanagedatMicrosoft...Iwishwealwaysputtheselessonsinto
action!"--JoeBelfiore,GeneralManager,E-homeDivision,MicrosoftCorporation
"Berkunhaswrittenafastpaced,jargon-freeandwittyguidetowhathewiselyrefersto
asthe'art'ofprojectmanagement.It'sagreatintroductiontothediscipline.Seasoned
andnewmanagerswillbenefitfromBerkun'sperspectives."
--JoeMirza,Director,CNETNetworks(Cnet.com)
"Mostbookswiththewords'projectmanagement'inthetitlearedrytomes.Ifthat'swhat
youareexpectingtohearfromBerkun'sbook,youwillbepleasantlysurprised.Sure,it's
aboutprojectmanagement.Butit'salsoaboutcreativity,situationalproblem-solving,and
leadership.Ifyou'reateammember,projectmanager,orevenanon-technical
stakeholder,Scottoffersdozensofpracticaltoolsandtechniquesyoucanuse,and
questionsyoucanask,toensureyourprojectssucceed."
--BillBliss,SeniorVPofproductandcustomerexperience,expedia.com
InTheArtofProjectManagement,you'lllearnfromaveteranmanagerofsoftwareand
webdevelopmenthowtoplan,manageandleadprojects.Thispersonalaccountofhard
lessonslearnedoveradecadeofworkintheindustrydistillscomplexconceptsand
challengesintopracticalnuggetsofusefuladvice.Inspiring,funny,honest,and
compelling,thisisthebookyouandyourteamneedtohavewithinarmsreach.Itwill


serveyouwellwithyourcurrentwork,andonfutureprojectstocome.
Topicsinclude:
Howtomakethingshappen
Makinggooddecisions
Specificationsandrequirements
Ideasandwhattodowiththem


Hownottoannoypeople
Leadershipandtrust
Thetruthaboutmakingdates
Whattodowhenthingsgowrong


TheArtofProjectManagement
ByScottBerkun
...............................................
Publisher:O'Reilly
PubDate:April2005
ISBN:0-596-00786-8
Pages:392

TableofContents|Index



















































Copyright
Preface
Whoshouldreadthisbook
AssumptionsI'vemadeaboutyouinwritingthisbook
Howtousethisbook
ChapterOne.Abriefhistoryofprojectmanagement(andwhyyoushouldcare)
Section1.1.Usinghistory
Section1.2.Webdevelopment,kitchens,andemergencyrooms
Section1.3.Theroleofprojectmanagement
Section1.4.ProgramandprojectmanagementatMicrosoft
Section1.5.Thebalancingactofprojectmanagement
Section1.6.Pressureanddistraction
Section1.7.Therightkindofinvolvement
Section1.8.Summary
PartI:Plans
ChapterTwo.Thetruthaboutschedules
Section2.1.Scheduleshavethreepurposes
Section2.2.Silverbulletsandmethodologies

Section2.3.Whatscheduleslooklike
Section2.4.Whyschedulesfail
Section2.5.Whatmusthappenforschedulestowork
Section2.6.Summary
ChapterThree.Howtofigureoutwhattodo
Section3.1.Softwareplanningdemystified
Section3.2.Approachingplans:thethreeperspectives


















































































Section3.3.Themagicalinterdisciplinaryview
Section3.4.Askingtherightquestions
Section3.5.Catalogofcommonbadwaystodecidewhattodo

Section3.6.Theprocessofplanning
Section3.7.Customerresearchanditsabuses
Section3.8.Bringingitalltogether:requirements
ChapterFour.Writingthegoodvision
Section4.1.Thevalueofwritingthingsdown
Section4.2.Howmuchvisiondoyouneed?
Section4.3.Thefivequalitiesofgoodvisions
Section4.4.Thekeypointstocover
Section4.5.Onwritingwell
Section4.6.Drafting,reviewing,andrevising
Section4.7.Acatalogoflamevisionstatements(whichshouldbeavoided)
Section4.8.Examplesofvisionsandgoals
Section4.9.Visionsshouldbevisual
Section4.10.Thevisionsanitycheck:dailyworship
Section4.11.Summary
ChapterFive.Whereideascomefrom
Section5.1.Thegapfromrequirementstosolutions
Section5.2.Therearebadideas
Section5.3.ThinkinginandoutofboxesisOK
Section5.4.Goodquestionsattractgoodideas
Section5.5.Badideasleadtogoodideas
Section5.6.Perspectiveandimprovisation
Section5.7.Thecustomerexperiencestartsthedesign
Section5.8.Adesignisaseriesofconversations
Section5.9.Summary
ChapterSix.Whattodowithideasonceyouhavethem
Section6.1.Ideasgetoutofcontrol
Section6.2.Managingideasdemandsasteadyhand
Section6.3.Checkpointsfordesignphases
Section6.4.Howtoconsolidateideas

Section6.5.Prototypesareyourfriends
Section6.6.Questionsforiterations
Section6.7.Theopen-issueslist
Section6.8.Summary
PartII:Skills

ChapterSeven.Writinggoodspecifications











































































Section7.1.Whatspecificationscanandcannotdo
Section7.2.Decidingwhattospecify
Section7.3.Specifyingisnotdesigning
Section7.4.Who,when,andhow
Section7.5.Whenarespecscomplete?
Section7.6.Reviewsandfeedback
Section7.7.Summary
ChapterEight.Howtomakegooddecisions
Section8.1.Sizingupadecision(what'satstake)
Section8.2.Findingandweighingoptions

Section8.3.Informationisaflashlight
Section8.4.Thecouragetodecide
Section8.5.Payingattentionandlookingback
Section8.6.Summary
ChapterNine.Communicationandrelationships
Section9.1.Managementthroughconversation
Section9.2.Abasicmodelofcommunication
Section9.3.Commoncommunicationproblems
Section9.4.Projectsdependonrelationships
Section9.5.Thebestworkattitude
Section9.6.Summary
ChapterTen.Hownottoannoypeople:process,email,andmeetings
Section10.1.Asummaryofwhypeoplegetannoyed
Section10.2.Theeffectsofgoodprocess
Section10.3.Non-annoyingemail
Section10.4.Howtorunthenon-annoyingmeeting
Section10.5.Summary
ChapterEleven.Whattodowhenthingsgowrong
Section11.1.Applytheroughguide
Section11.2.Commonsituationstoexpect
Section11.3.Takeresponsibility
Section11.4.Damagecontrol
Section11.5.Conflictresolutionandnegotiation
Section11.6.Rolesandclearauthority
Section11.7.Anemotionaltoolkit:pressure,feelingsaboutfeelings,andthe

herocomplex

Section11.8.Summary


PartIII:Management

ChapterTwelve.Whyleadershipisbasedontrust

















































































Section12.1.Buildingandlosingtrust

Section12.2.Maketrustclear(creategreenlights)
Section12.3.Thedifferentkindsofpower
Section12.4.Trustingothers
Section12.5.Trustisinsuranceagainstadversity
Section12.6.Models,questions,andconflicts
Section12.7.Trustandmakingmistakes

Section12.8.Trustinyourself(self-reliance)
Section12.9.Summary
ChapterThirteen.Howtomakethingshappen
Section13.1.Prioritiesmakethingshappen
Section13.2.Thingshappenwhenyousayno
Section13.3.Keepingitreal
Section13.4.Knowthecriticalpath
Section13.5.Berelentless
Section13.6.Besavvy
Section13.7.Summary
ChapterFourteen.Middle-gamestrategy
Section14.1.Flyingaheadoftheplane
Section14.2.Takingsafeaction
Section14.3.Thecodingpipeline
Section14.4.Hittingmovingtargets
Section14.5.Summary
ChapterFifteen.End-gamestrategy
Section15.1.Bigdeadlinesarejustseveralsmalldeadlines
Section15.2.Elementsofmeasurement
Section15.3.Elementsofcontrol
Section15.4.Theendofend-game
Section15.5.Partytime
Section15.6.Summary
ChapterSixteen.Powerandpolitics
Section16.1.ThedayIbecamepolitical
Section16.2.Thesourcesofpower
Section16.3.Themisuseofpower
Section16.4.Howtosolvepoliticalproblems
Section16.5.Knowtheplayingfield
Section16.6.Summary

Notes

ChapterOne






















































ChapterTwo
ChapterThree
ChapterFour
ChapterFive

ChapterSix
ChapterSeven
ChapterEight
ChapterNine
ChapterTen
ChapterEleven
ChapterTwelve
ChapterThirteen
ChapterFourteen
ChapterFifteen
ChapterSixteen
AnnotatedBibliography
Philosophyandstrategy
Psychology
History
Managementandpolitics
Science,engineering,andarchitecture
Softwareprocessandmethodology
Acknowledgments


PhotoCredits
Colophon

AbouttheAuthor

Colophon
Index



TheArtofProjectManagement
byScottBerkun
Copyright©2005O'ReillyMedia,Inc.
Allrightsreserved.
PrintedintheUnitedStatesofAmerica.
PublishedbyO'ReillyMedia,Inc.,
1005GravensteinHighwayNorth
Sebastopol,CA95472.
O'Reillybooksmaybepurchasedforeducational,business,or
salespromotionaluse.Onlineeditionsarealsoavailablefor
mosttitles(safari.oreilly.com).Formoreinformation,contact
ourcorporate/institutionalsalesdepartment:(800)998-9938or

Editor:

MikeHendrickson

ProductionEditor:

MarloweShaeffer
MENDEDESIGN,

CoverDesigner:
www.mendedesign.com
InteriorDesigner:

MarciaFriedman

ArtDirector:


MicheleWetherbee

PrintingHistory:

April2005:

FirstEdition.




TheO'ReillylogoisaregisteredtrademarkofO'ReillyMedia,
Inc.Manyofthedesignationsusedbymanufacturersandsellers
todistinguishtheirproductsareclaimedastrademarks.Where
thosedesignationsappearinthisbook,andO'ReillyMedia,Inc.
wasawareofatrademarkclaim,thedesignationshavebeen
printedincapsorinitialcaps.
Whileeveryprecautionhasbeentakeninthepreparationofthis
book,thepublisherandauthorassumenoresponsibilityfor
errorsoromissions,orfordamagesresultingfromtheuseof
theinformationcontainedherein.
ISBN:0-596-00786-8
[C][7/05]


Preface

MyfavoritewordintheEnglishlanguageishow.How
doesthiswork?Howwasthismade?Howdidtheydothis?
WheneverIseesomethinginterestinghappen,I'mfilledwith

questionsthatinvolvethissmallbutpowerfullittleword.And
mostoftheanswersIfindcenteronhowpeopleapplytheir
ownintelligenceandwisdom,ratherthantheirknowledgeof
specifictechnologiesortheories.
Overyearsofbuildingthingsandcomparingmyexperiencesto
thoseofothermanagers,programmers,anddesigners,I've
developedbeliefsandconclusionsabouthowtomanage
projectswell.Thisbookisasummationofthoseideas.It
includesapproachesforleadingteams,workingwithideas,
organizingprojects,managingschedules,dealingwithpolitics,
andmakingthingshappen,eveninthefaceofgreatchallenges


andunfairsituations.
Despitethebroadtitleofthisbook,mostofmyworking
experiencecomesfromthetechsector,andinparticular,
MicrosoftCorporation.Iworkedtherefrom1994to2003,
leadingteamsofpeopleonprojectssuchasInternetExplorer,
MicrosoftWindows,andMSN.ForafewyearsIworkedin
Microsoft'sengineeringexcellencegroup.Whilethere,Iwas
responsibleforteachingandconsultingwithteamsacrossthe
company,andwasoftenaskedtolectureatpublicconferences,
corporations,anduniversities.Mostoftheadvice,lessons,and
storiesinthisbookcomefromtheseexperiences.
AlthoughIcomefromasoftwareandwebdevelopment
background,I'vewrittenthisbookbroadlyandinclusively,
callingonreferencesandtechniquesfromoutsidethe
engineeringandmanagementdomains.Thereisgreatvalue
hereforpeopleinthegeneralbusinessworld.I'mconvinced
thatthechallengesoforganizing,leading,designing,and

deliveringworkhavemuchincommon,regardlessofthe
domain.Theprocessesinvolvedinmakingtoasterovens,
skyscrapers,automobiles,websites,andsoftwareproducts
sharemanyofthesamechallenges,andthisbookisprimarily
aboutovercomingthosechallenges.
Unlikesomeotherbooksonhowtoleadprojectsandteams,
thisbookdoesn'tascribetoanygrandtheoryorpresumptively
innovativephilosophy.Instead,I'veplacedmybeton
practicalityanddiversity.Ithinkprojectsresultingoodthings
whentherightcombinationofpeople,skills,attitudes,and
tacticsisapplied,regardlessoftheiroriginor(lackof)pedigree.
ThestructureofthisbookisthemostsensibleoneIfound:
focusonthecorechallengesandsituations,andprovideadvice
onhowtohandlethemwell.I'vebetheavilyonpickingthe
righttopicsandgivinggoodadviceonthem,overallother
considerations.IhopeyoufindthatI'vemadetherightchoice.


Whoshouldreadthisbook
Yourbestbetinseeingifthisbookisforyouinvolvesflipping
backtotheTableofContents,pickingatopicyou'reinterested
in,andskimmingthroughwhatIhavetosayaboutit.I
generallydon'ttrustprefacesmuch,andIrecommendyou
don'teither;theyrarelyhavethesamestyleorvoiceasthe
restofthebook.Butheregoesanyway.
Thebookwillbemostvaluableforpeoplewhofitthemselves
intooneormoreofthefollowingcategories:
Experiencedteamleadersandmanagers.Thisbookis
wellsuitedforanyoneplayingaleadershiprole,formallyor
informally,onanykindofproject.Theexamplesarefrom

softwaredevelopment,butmanyconceptsapplyeasilyto
otherkindsofwork.Youmightbetheofficialteamleader,
orsimplyoneofthemoreexperiencedpeopleontheteam.
Whilesomeofthetopicsofthebookmaybeveryfamiliar
toyou,thedirectandpracticalapproachthebooktakeswill
helpyoutoclarifyandrefineyouropinions.Evenifyou
disagreewithpointsImake,youwillhaveaclear
foundationtoworkagainstinrefiningandimprovingyour
ownpointofview.
Newteamleadersandmanagers.Ifyoulookatthe
topicslistedintheTableofContents,you'llfindasolid
overviewofeverythingleadersandmanagersonprojects
actuallydo.Eachchapterprovidescoverageofthecommon
failuresandmistakesevenexperiencedpeoplemake,with
explanationsastowhyithappensandwhattacticscanbe
usedtoavoidorrecoverfromthem.Thebookprovidesyou
withabroaderviewandunderstandingofthenew
responsibilitiesyou'vetakenon,andthesmartestwaysto
goaboutmanagingthem.Becausemostchapterstakeon


bigtopics,theyoftenincludeannotatedreferencesto
deepersources.
Individualprogrammersandtesters,orother
contributorstoprojects.Thisbookwillimproveyour
understandingofwhatyou'recontributingto,andwhat
approachesandideasyoucanusetobeeffectiveandhappy
indoingso.Ifyou'veeverwonderedwhyprojectschange
directionssooftenorseemtobepoorlymanaged,thisbook
willhelpyouunderstandthecausesandremedies.If

nothingelse,readingthisbookwillhelpyoutoframeyour
individualcontributionsinalargercontext,andincreasethe
oddsthatyourworkwillmakeadifference(andthatyou
willstaysanewhiledoingit).Ifyouareinterestedin
eventuallymanagingorleadingteamsyourself,thisbook
willhelpyouexplorewhatthatwillreallybelikeand
whetheryouarecutoutforit.
Studentsofbusinessmanagement,productdesign,or
softwareengineering.Iusethewordstudentsinthe
broadestsense:ifyouhaveapersonalinterestinthese
topicsorareformallystudyingthem,thisbookshouldbeof
greatinteresttoyou.Unlikemuchofthetextbookcoverage
ofthesetopics,thisbookisheavilysituationandnarrative
focused.Theexperiencesandstoriesarereal,andtheyare
thebasisforthelessonsandtactics:nottheotherway
around.Ideliberatelyavoiddrawinglinesbetweendifferent
academicsubjectsbecauseinmyexperience,thoselines
neitherhelpprojectsnorcontributetounderstandingreality
(theuniverseisnotdividedinthesamewayuniversities
tendtobe).Instead,thisbookcombinesbusinesstheory,
psychology,managementtactics,designprocesses,and
softwareengineeringinwhateverwaynecessarytooffer
adviceontheoutlinedtopics.


AssumptionsI'vemadeaboutyouinwritingthis
book
Youarenotstupid.IassumethatifI'vepickedtheright
chaptersandwritethemwell,youwon'tneedmetospend
timeslowlyconstructingelaborateframeworksof

information.Instead,Iwillgettothepointandspendtime
there.Iassumeyou'resomethingofapeerperhapswith
more,less,ordifferentexperiencewhohasdroppedbyfor
someadvice.
Youarecuriousandpragmatic.Idrawonexamplesand
referencesfrommanydisciplines,andIassumeyou'llfind
valueinpullinglessonsfromoutsideofwebandsoftware
development.Thiswon'tgetintheway,butpointersfor
curiousmindswillsurface,sometimesjustinfootnotes.I
assumeyouwanttolearn,areopentodifferentideas,and
willrecognizethevalueofwell-consideredopinionsevenif
youdon'tagreewiththem.
Youdonotlikejargonorbigtheories.Idon'tthink
jargonandbigtheorieshelpinlearningandapplyingnew
information.Iavoidthem,exceptwheretheyprovidea
pathtousefulinformationorprovidestructurethatwillbe
usefullateron.
Youdon'ttakeyourself,software,ormanagementtoo
seriously.Softwaredevelopmentandprojectmanagement
canbeboringtoreadabout.Whilethisbookwon'tbea
comicalromporsatire(althoughabookbyMarkTwainor
DavidSedaristhatexplainssoftwareengineeringhas
potential),Iwon'thesitatetomakejokesatmyexpense(or
someoneelse'sexpense),oruseexamplesthatmakea
pointthroughcomedicmeans.


Howtousethisbook
Iwrotethisbookwithconsiderationforpeoplewholiketoskip
aroundandreadchaptersindividually.However,thereissome

benefittoreadingitstraightthrough;someofthelater
conceptsbuildonearlierones,andthebookdoesroughlyfollow
thechronologicalorderofmostprojects.Ofcourse,you'dnever
knowthisunlessyoureaditstraightthrough,soifyouchoose
toskiparound,you'llhavetotrustmeonthisone.
Thefirstchapteristhebroadestinthebookandhasadeeper
tonethantherest.Ifyou'recuriousaboutwhyyoushouldcare
aboutprojectmanagement,orwhatotherimportantpeople
havesaidaboutit,thenyoushoulddefinitelygiveitashot.If
youtryitandhateit,Idefinitelyrecommendgivinganother
chapteratrybeforeabandoningship.
AllofthereferencesandURLslistedinthebook,aswellas
additionalnotesandcommentary,areonlineat
www.scottberkun.com/books/artofpm/.Thewebsitehasa
discussionforumandotherresourcesforthoseofyouwhoare
interestedingoingbeyondthetopicsinthisbook.
Andnow,becauseyouweresmartandpatientenoughtoread
thisentireintroduction,I'llassumeyou'reuptospeedonthe
othermechanicsofbookreading(pagenumbers,footnotes,and
allthat)andjustgetoutofyourway.
Cheers,
ScottBerkun
Redmond,WA


ChapterOne.Abriefhistoryofproject
management(andwhyyoushouldcare)

Inmanyorganizations,thepersonleadingaprojectdoesn't
havethejobtitleprojectmanager.That'sOK.Programmers,

managers,teamleaders,testers,anddesignersallmanage
projectsintheirdailywork,whethertheyareworkingaloneor
leadingateam.Forthemoment,thesedistinctionsarenot
important.Myintentinthisbookistocapturewhatmakes
projectssuccessfulandhowthepeoplewholeadsuccessful
projectsdoit.Thesecoreideasandstrategiesdon'trequire
specifichierarchies,jobtitles,ormethods.So,ifyouworkona
projectandhaveatleastsomeresponsibilityforitsoutcome,
whatfollowswillapplytoyou.Andshouldyourbusinesscard
happentosayprojectmanageronit,allthebetter.


Thisbookisdesignedtobeusefulinthreeways:asacollection
ofindividualtopic-focusedessays,asasingleextended
narrative,andasareferenceforcommonsituations.Each
chaptertakesonadifferenthigh-leveltask,providesabasic
framework,andoffersstrategiesandtacticsforsuccessfully
completingthetask.However,inthisopeningchapter,Ineedto
takeadifferentapproach:therearethreebroadertopicsthat
willmaketherestofthebookeasiertofollow,andIwillpresent
themnow.
Thefirstisashorthistoryofprojectsandwhyweshouldlearn
fromwhatothershavedone.Thesecondissomebackground
onthedifferentflavorsofprojectmanagement,includingsome
notesfrommyexperienceworkingatMicrosoft.Andthethirdis
alookattheunderlyingchallengesinvolvedinproject
managementandhowtheycanbeovercome.Althoughthese
pointswillbeusefullateron,theyarenotrequiredto
understandthefollowingchapters.So,ifyoufindtheapproach
inthisfirstchaptertoowideforyourliking,feelfreetomoveon

toChapter2andthecoreofthisbook.


1.1.Usinghistory
Projectmanagement,asanidea,goesbackaverylongway.If
youthinkaboutallofthethingsthathavebeenbuiltinthe
historyofcivilization,wehavethousandsofyearsofproject
experiencetolearnfrom.Adottedlinecanbedrawnfromthe
softwaredevelopersoftodaybackthroughtimetothebuilders
oftheEgyptianpyramidsorthearchitectsoftheRoman
aqueducts.Fortheirrespectiveeras,projectmanagershave
playedsimilarroles,applyingtechnologytotherelevant
problemsofthetimes.Yettoday,whenmostpeopletryto
improvehowtheirwebandsoftwaredevelopmentprojectsare
managed,it'srarethattheypayattentiontolessonslearned
fromthepast.Thetimelineweuseasthescopeforuseful
knowledgeismuchclosertopresentdaythanitshouldbe.
Thehistoryofengineeringprojectsrevealsthatmostprojects
havestrongsimilarities.Theyhaverequirements,designs,and
constraints.Theydependoncommunication,decisionmaking,
andcombinationsofcreativeandlogicalthought.Projects
usuallyinvolveaschedule,abudget,andacustomer.Most
importantly,thecentraltaskofprojectsistocombinetheworks
ofdifferentpeopleintoasingularcoherentwholethatwillbe
usefultopeopleorcustomers.Whetheraprojectisbuiltoutof
HTML,C++,orcementandsteel,there'sanundeniablecoreset
ofconceptsthatmostprojectsshare.
Curiousaboutbetterwaystoleadwebandsoftware
developmentefforts,I'vetakenaseriousinterestinthatcore.I
studiedotherfieldsandindustriestoseehowtheysolvedthe

centralchallengestotheirprojects,soIcouldapplycomparable
solutionsinmyownwork.Iwonderedhowprojectslikethe
HubbleSpaceTelescopeandtheBoeing777weredesignedand
constructed.CouldIreuseanythingfromtheircomplex
specificationsandplanningprocesses?OrwhentheChrysler
BuildingwasbuiltinNewYorkCityandtheParthenonin


Athens,didtheprojectleadersplanandestimatetheir
constructioninthesamewaymyprogrammersdid?Whatwere
theinterestingdifferences,andwhatcanbegainedby
examiningthosedifferences?
Howaboutnewspapereditors,whoorganizeandplanfordaily
productionofinformation?Theyweredoingmultimedia
(picturesandwords)longbeforethefirstdreamsofweb
publishing.Whataboutfeaturefilmproduction?TheApollo13
launch?Byexaminingthesequestions,Iwasabletolookat
howIwentaboutleadingprojectteamsinanewway.
However,theseinquiresdidn'talwaysprovideobviousanswers.
Ican'tpromisethatyou'llshipsoonerorplanbetterspecifically
becausetheadviceinthisbookwasinfluencedbythese
sources.ButIdoknowthatwhenIreturnedtothesoftware
worldafterlookingelsewhere,myownprocessesandtools
lookeddifferenttome.IfoundwaystochangethemthatI
hadn'tconsideredbefore.Onthewhole,Irealizedthatmanyof
theusefulapproachesandcomparisonsIfoundwerenever
mentionedduringmycomputersciencestudiesincollege.They
wereneverdiscussedattech-sectorconferencesorwritten
aboutintrademagazines.
Thekeylessonsfrommyinquiriesintothepastarethe

followingthreepoints:
1. Projectmanagementandsoftwaredevelopmentare
notsacredarts.Anymodernengineeringworkisonenew
entryinthelonghistoryofmakingthings.Thetechnologies
andskillsmaychange,butmanyofthecorechallengesthat
makeengineeringdifficultremain.Allthings,whether
programminglanguagesordevelopmentmethodologies,are
uniqueinsomewaysbutderivativeinothers.Butifwe
wanttoreuseasmuchknowledgeaswecanfromthepast,
weneedtomakesurewe'reopentoexaminingboth
aspectstheuniqueandthederivativeincomparingwithwhat
hascomebefore.


2. Thesimpleryourviewofwhatyoudo,themore
powerandfocusyouwillhaveindoingit.Ifwecan
periodicallymaintainasimpleviewofourwork,wecanfind
usefulcomparisonstootherwaystomakethingsthatexist
allaroundus.Therewillbemoreexamplesandlessons
fromhistoryandmodernindustriesthatcanbepulledfrom,
comparedwith,andcontrastedagainst.Thisissimilarto
theconceptdefinedbytheJapanesewordshoshin,which
meansbeginner'smind,(1)oropenmind,anessentialpart
ofmanymartialartsdisciplines.Stayingcuriousandopenis
whatmakesgrowthpossible,anditrequirespracticeto
maintainthatmindset.Tokeeplearning,wehavetoavoid
thetemptationtoslideintonarrow,safeviewsofwhatwe
do.
3. Simpledoesn'tmeaneasy.Thebestathletes,writers,
programmers,andmanagerstendtobetheoneswho

alwaysseewhattheydoassimpleinnaturebut
simultaneouslydifficult.Rememberthatsimpleisnotthe
samethingaseasy.Forexample,it'sasimplethingtorun
amarathon.Youstartrunninganddon'tstopuntilyou've
reached26.2miles.Whatcouldbesimpler?Thefactthat
it'sdifficultdoesn'tnegateitssimplicity.Leadershipand
managementarealsodifficult,buttheirnaturegetting
thingsdoneinaspecificwaytowardaspecificgoalissimple.
I'llalludetotheseconceptsinmanychapters.So,ifImake
referencesthatareoutofthestereotypicalboundsofsoftware
development,Ihopeyou'llunderstandmyreasonsfordoingso.
AndwhenIsuggestthatdecisionmakingorschedulingare
simplemanagementfunctions,I'llassumeyou'llknowthatthis
innowaysuggeststhesethingsareeasytodo.

1.1.1.Learningfromfailure
"Humanbeings,whoarealmostunique[among


animals]inhavingtheabilitytolearnfromthe
experienceofothers,arealsoremarkablefortheir
apparentdisinclinationtodoso."
DouglasAdams
Onesimplequestionthatarisesinstudyingthehistoryof
projectsisthis:whywouldanyonewillinglysufferthrough
mistakesanddisappointmentsiftheycouldbeavoided?Ifthe
historyofbothancientandmodernengineeringis(largely)in
thepublicdomain,andwegetpaidfordoingsmartthings
regardlessofwheretheinspirationcamefrom,whydosofew
organizationsrewardpeopleforharvestinglessonsfromthe

past?Asprojectsarecompletedorarecanceled(andmany
developmentprojectsendthisway(2))everyday,littleisdone
tolearnfromwhathappened.Itseemsthatmanagersinmost
organizationsrarelyrewardpeopleforseekingoutthiskindof
knowledge.Perhapsit'sfearofwhatthey'llfind(andthefearof
beingheldaccountableforit).Ormaybeit'sjustalackof
interestonanyone'sparttoreviewpainfulorfrustrating
experienceswhentimecouldbespentmovingontothenext
newthinginstead.
InHenryPetroski'sbookToEngineerIsHuman:TheRoleof
FailureinSuccessfulDesign(VintageBooks,1992),heexplains
howmanybreakthroughsinengineeringtookplaceasaresult
offailure.Inpart,thishappensbecausefailuresforceustopay
attention.Theydemandustore-examineassumptionswe'd
forgottenwerethere(it'shardtopretendeverything'sOKwhen
theprototypehasburstintoflames).AsKarlPopper(3)
suggested,thereareonlytwokindsoftheories:thosethatare
wrongandthosethatareincomplete.Withoutfailure,we
forget,inarrogance,thatourunderstandingofthingsisnever
ascompleteaswethinkitis.
Thetrickthenistolearnasmuchaspossiblefromother
people'sfailures.Weshouldusetheirexperiencestoleverage


againstthefuture.Whilethesuperficialdetailsoffailuremight
differdramaticallyfromprojecttoproject,therootcausesor
teamactionsthatledtothemmightbeentirelytransferable
(andavoidable).Evenonourownprojects,weneedtoavoid
thehabitofrunningawayandhidingfromfailures.Instead,we
shouldseethemasopportunitiestolearnsomething.What

factorscontributedtoithappening?Whichonesmightbeeasy
tominimizeoreliminate?AccordingtoPetroski,realknowledge
fromrealfailureisthemostpowerfulsourceofprogresswe
have,providedwehavethecouragetocarefullyexaminewhat
happened.
PerhapsthisiswhyTheBoeingCompany,oneofthelargest
airplanedesignandengineeringfirmsintheworld,keepsa
blackbookoflessonsithaslearnedfromdesignand
engineeringfailures.(4)Boeinghaskeptthisdocumentsince
thecompanywasformed,anditusesittohelpmodern
designerslearnfrompastattempts.Anyorganizationthat
managestodothisnotonlyincreasesitschancesforsuccessful
projects,butalsohelpscreateanenvironmentthatcandiscuss
andconfrontfailureopenly,insteadofdenyingandhidingfrom
it.Itseemsthatsoftwaredevelopersneedtokeepblackbooks
oftheirown.


1.2.Webdevelopment,kitchens,andemergency
rooms
Oneproblemwithhistoryisthatit'snotalwaysrelatable.Itcan
behardtoapplylessonsacrossdecadesandsustainempathy
forthingsthatseemsodifferentfromhowworkisdonetoday.
Onealternativeistomakecomparisonswithinterestingkindsof
modernprojects.Whilethisdoesn'thavethegravitasof
engineeringhistory,itdoesallowforfirst-personexperiences
andobservations.Often,seeingthingsfirsthandistheonlyway
togivepeopleenoughinformationtomakeconnectionsamong
diverseideas.
Asanexample,Iknowawebdeveloperwhobelievesthathis

workisunlikeanythingelseinthehistoryoftheuniverse.He
feelsthatbecausewebdevelopmentrequireshimtomake
complexengineeringdecisionsdesigningandcoordinatingashe
goes,verifyingchangesinamatterofhoursorevenminutes,
andthenpublishingitalltotheworldhisprojectandtask
managementisunlikeanythingeverseenbefore.Heisproudto
rattleoffCSS,XHTML,Flash,Java,andothertechnologieshe
hasmastered,claimingthattheywouldhavebaffledthe
greatestminds50yearsago.I'msurethatinyourexperience,
you'vemetpeoplelikehim.Orperhapsyouhaveworkedin
situationswhereitseemedimprobablethatanyoneelseinthe
universeevermanagedanythingascomplexaswhatyouwere
doing.
Isuggestedtothisdeveloperfriendthathewanderintothe
backofhisfavoritelunchestablishmentonabusyday.Fora
varietyofreasons,it'sinterestingtostepfootintokitchens(see
AnthonyBourdain'sexcellentbook,KitchenConfidential,Ecco,
2001),butmyspecificpointwasaboutproductivity.Thefirst
timeanyoneseesthequicktaskmanagementandcoordination
thatoccurinabusyprofessionalkitchen,he'slikelyto


reconsiderhowdifficulthisownjobis.Cooksareoftenjuggling
fryingpanswithdifferentordersatdifferentstatesof
completion,andscramblingbetweenmultiplesetsofburnersin
oppositecornersofthekitchen,whilewaitersruninandout,
deliveringnewsofnewadjustmentsandproblemsfrom
customers.
Allofthishappensinsmall,crampedrooms,wellover90
degrees,withbrightfluorescentlightsglaringabove.And

despitehowmanyordersgoouteveryfewseconds,newones
comeinjustasfast.Sometimesordersgetsentback,or,much
likesoftwareprojects,requirecustomandlast-minute
modifications(table1islactoseintolerant;table2needsthe
sauceontheside,etc.).Large,busykitchensareamazingto
watch.Aschaoticastheymayseematfirst,greatkitchensrun
withalevelofintensityandprecisionthatblowsmost
developmentteamsaway.
Workingchefsandlinecooksareculinaryprojectmanagers,or
asBourdainreferstothem,airtrafficcontrollers(another
professionfortheintrospectivetoconsider).Eventhough
kitchenstaffworksonascalesmallerandlesscelebratedthan
amanagerofasoftwaredevelopmentteam,there'sno
comparisonfordailyintensity.Ifyoudoubtme,nexttime
you'reatthatbusylunchplace,askyourserverifyoucanpeek
insidethekitchen.Hemightnotletyou,butifhedoes,youwill
notbedisappointed.(Sometrendierrestaurantsandbarshave
openkitchens.Ifyoufindone,sitasclosetothekitchenasyou
can.Thenfollowonepersonforafewminutes.Watchhow
ordersareplaced,tracked,constructed,anddelivered.Ifyou
goonabusyday,you'llthinkdifferentlyabouthowsoftware
bugsareopened,tracked,andfixed.)
Anotherinterestingfieldlessoninprojectmanagementcomes
fromhospitalemergencyrooms.I'vewatchedontheDiscovery
ChannelandPBShowsmallteamsofexpertdoctors,nurses,
andspecialistsworktogetherasaprojectteamtotreatthe
diverseandsometimesbizarremedicalsituationsthatcome


throughthehospitaldoors.It'snotsurprisingthatthisisthe

professionthatinventedtheprocessoftriage,atermcommonly
usedonsoftwareprojectstoprioritizeissuesanddefects
(discussedinChapter15).
Themedicalenvironment,especiallytraumasituations,offersa
fascinatingcomparisonforteam-basedwork,high-stress
decisionmaking,andprojectoutcomesthataffectmanypeople
everyday(seeFigure1-1foraroughcomparisonofthisand
otherworkenvironments).AsAtulGawandewroteinhis
excellentbook,Complications:ASurgeon'sNotesonan
ImperfectScience(PicadorUSA,2003):
Welookformedicinetobeanorderlyfieldofknowledge
andprocedure.Butitisnot.Itisanimperfectscience,an
enterpriseofconstantlychangingknowledge,uncertain
information,fallibleindividuals,andatthesametimelives
ontheline.Thereisscienceinwhatwedo,yes,butalso
habit,intuition,andsometimesplainoldguessing.The
gapbetweenwhatweknowandweaimforpersists.And
thisgapcomplicateseverythingwedo.

Figure1-1.Intheabstract,manydisciplineshave
similarprocesses.Theyalldedicatetimeto
planning,executing,andrefining.(However,you
shouldnevergotoakitchenformedical
treatmentoreatinanemergencyroom.)


×