The Art of Project Management:

How to Make Things Happen

Summary: In this chapter excerpt from his book, The Art of Project Management, Scott Berkun recounts what it
took for him to be successfu at Microsoft as a project manager! "#$ printe% pages&
'ontents
Priorities Make Things Happen
Things Happen (hen )ou Sa* +o
,eeping It -ea
,now the 'ritica Path
Be -eentess
Be Sa..*
Summar*
/ne m*th of project management is that certain peope ha.e an innate abiit* to %o it we, an% others %o not!
(hene.er this m*th came up in con.ersation with other project managers, I awa*s aske% for an expanation of
that abiit*0how to recogni1e it, categori1e it, an%, if possibe, %e.eop it in others! After %iscussion an% %ebate,
the on* thing we usua* i%enti2e%0after consi%ering man* of the other topics an% skis co.ere% esewhere in
this book0is the abiit* to make things happen! Some peope are abe to app* their skis an% taents in
whate.er combination necessar* to mo.e projects forwar%, an% others cannot, e.en if the* ha.e the same or
superior in%i.i%ua skis! The abiit* to make things happen is a combination of knowing how to be a cata*st or
%ri.er in a .ariet* of %i3erent situations, an% ha.ing the courage to %o so!
This abiit* to %ri.e is so important to some that it4s use% as a itmus test in hiring project managers! 5.en if PMs
can4t precise* %e2ne what the abiit* is without making at east some references to other skis, the* %o fee that
the* can sense or measure it in others! 6or exampe, an inter.iewer nee%s to ask hersef the foowing 7uestion
about the can%i%ate: 8If things were not going we on some important part of the project, wou% I fee con2%ent
sen%ing this person into that room, into that %iscussion or %ebate, an% beie.e he4% hep 2n% a wa* to make it
better, whate.er the probem was98 If after a roun% of inter.iews the answer is no, the can%i%ate is sent home!
The beief is that if he isn4t agie or :exibe enough to a%apt his skis an% knowe%ge to the situations at han%,
an% 2n% wa*s to %ri.e things forwar%, then he won4t sur.i.e, much ess thri.e, on a t*pica project! This chapter
is about that abiit* an% the skis an% tactics in.o.e%!
Priorities Make Things Happen
A arge percentage of m* time as a PM was spent making or%ere% ists! An or%ere% ist is just a coumn of things,
put in or%er of importance! I4m con.ince% that %espite a of the knowe%ge an% skis I was expecte% to ha.e an%
use, in tota, a I rea* %i% was make or%ere% ists! I coecte% things that ha% to be %one0re7uirements,
features, bugs, whate.er0an% put them in an or%er of importance to the project! I spent hours an% %a*s re2ning
an% re.ising these ists, integrating new i%eas an% information, %ebating an% %iscussing them with others,
awa*s making sure the* were rock soi%! Then, once we ha% that ist in pace, I4% %ri.e an% ea% the team as
har% as possibe to foow things in the %e2ne% or%er! Sometimes, these ists in.o.e% how m* own time shou%
be spent on a gi.en %a*; other times, the ists in.o.e% what entire teams of peope wou% %o o.er weeks or
months! But the process an% the e3ect were the same!
I in.este% so much time in these ists because I knew that ha.ing cear priorities was the backbone of progress!
Making things happen is %epen%ent on ha.ing a cear sense of which things are more important than others an%
app*ing that sense to e.er* singe interaction that takes pace on the team! These priorities ha.e to be
re:ecte% in e.er* emai *ou sen%, 7uestion *ou ask, an% meeting *ou ho%! 5.er* programmer an% tester shou%
in.est energ* in the things that wi most ike* bring about success! Someone has to be %e%icate% to both
2guring out what those things are an% %ri.ing the team to %ei.er on them!
(hat sows progress an% wastes the most time on projects is confusion about what the goas are or which things
shou% come before which other things! Man* miscommunications an% missteps happen because person A
assume% one priorit* "make it faster&, an% person B assume% another "make it more stabe&! This is true for
programmers, testers, marketers, an% entire teams of peope! If these con:icts can be a.oi%e%, more time can
be spent actua* progressing towar% the project goas!
This isn4t to sa* those %ebates about priorities shou%n4t happen0the* shou%! But the* shou% happen ear* as
part of whate.er panning process *ou4re using! If the same arguments keep resurfacing %uring %e.eopment, it
means peope were not e3ecti.e* con.ince% of the %ecision, or the* ha.e forgotten the ogic an% nee% to be
remin%e% of wh* those %ecisions were ma%e! 5ntertain %ebates, but start b* asking if an*thing has change%
since the pans were ma%e to justif* reconsi%ering the priorities! If nothing has change% "competitor beha.ior,
new group mission, more<ess resources, new major probems&, stick to the %ecision!
If there is an or%ere% ist poste% up on the wa carif*ing for e.er*one which things ha.e been agree% to be
more important than which other things, these arguments en% 7uick* or ne.er e.en start! /r%ere% ists pro.i%e
e.er*one with a share% framework of ogic to inherit their %ecisions from! If the goas are cear an% un%erstoo%,
there is ess nee% for interpretation an% fewer chances for waste% e3ort!
So, if e.er things on the team were not going we an% peope were ha.ing troube focusing on the important
things, I knew it was m* faut: either I ha%n4t or%ere% things proper*, ha%n4t e3ecti.e* communicate% those
priorities, or ha% faie% to execute an% %ei.er on the or%er that we ha%! In such a case, working with
prioriti1ation an% or%ere% ists meant e.er*thing!
'ommon or%ere% ists
B* awa*s working with a set or%er of priorities, a%justments an% changes are eas* to make! If, b* some mirace,
more time or resources are foun% in the sche%ue, it4s cear what the next most important item is to work on! B*
the same token, if the sche%ue nee%s to be cut, e.er*one knows what the next east important item is an% can
stop working on it! This is incre%ib* important because it guarantees that no matter what happens, *ou wi
ha.e %one the most important work possibe an% can make 7uick a%justments without much e3ort or negati.e
morae! Aso, an* prioriti1ation mistakes *ou make wi be reati.e: if work item #= turns out to ha.e been more
important than work item >, big %ea! Because the whoe ist was in or%er, *ou won4t ha.e ma%e a horribe
mistake! An% besi%es, b* ha.ing such cear priorities an% keeping the team focuse% on them, *ou ma* .er* we
ha.e bought the time nee%e% to get work item #= %one after a!
6or most projects, the three most important an% most forma or%ere% ists are use% to prioriti1e project goas,
features, an% work items "see 6igure #?@#&! The project goas are t*pica* part of the .ision %ocument "see
'hapter A& or are %eri.e% from it! The ists of features an% work items are the output of the %esign process "see
'hapters B, $, an% C&! Because each of these ists inherits priorities from the prece%ing ist, b* stepping up a
e.e to reach a point of carit* an% then reapp*ing those priorities back %own to the e.e in 7uestion, an*
%isputes can begin to be reso.e%! Athough this ma* not awa*s reso.e %ebates, it wi make sure that e.er*
%ecision was ma%e in the context of what4s tru* important!
Figure 13-1. The three most important ordered lists, shown in order.
/ther important things that might nee% or%ere% ists incu%e bugs, customer suggestions, empo*ee bonuses,
an% team bu%gets! The* can a be manage% in a simiar wa*: put things in the or%er most ike* to make the
project or organi1ation successfu! +o matter how compex the toos *ou use are "sa*, for bug tracking&, ne.er
forget that a *ou4re %oing is or%ering things! If the toos or processes *ou use %on4t hep *ou put things in or%er
an% carr* out that or%er, 2n% a %i3erent too or process! Bug triage, for exampe, where peope get in a room
an% %eci%e when a bug shou% be 2xe% "if at a&, is rea* just a group process for making an or%ere% ist of bugs!
The bugs might be cassi2e% b* group rather than on an in%i.i%ua bug@b*@bug basis, but the purpose an% e3ect
are the same!
If *ou %o use the three most common or%ere% ists, make sure that the* awa*s map to each other! 5.er*
engineering work item shou% map to a feature, an% e.er* feature shou% map to a goa! If a new work item is
a%%e%, it must be matche% against features an% goas! This is a forcing function to pre.ent ran%om features! If a
DP or programmer wants to sip something extra in, she shou% be force% to justif* it against what the project is
tr*ing to achie.e: 8That4s a great feature, boss, but which goa wi it hep us satisf*9 5ither we shou% a%just the
goas an% %ea with the conse7uences, or we shou%n4t be in.esting energ* here!8 If *ou teach the team that it4s
a rue to keep these three e.es of %ecision making in s*nc, *ou wi focus the team an% pre.ent them from
wasting time!
Priorit* # .ersus e.er*thing ese
T*pica*, these or%ere% ists ha.e one important ine %i.i%ing them into two pieces! The top part is priorit* #:
things we must %o an% cannot possib* succee% without! The secon% part is e.er*thing ese! Priorities E an% ?
exist but are un%erstoo% to be entire* %i3erent kin%s of things from priorit* #! It is .er* %iFcut to promote
priorit* E items into priorit* #!
This priorit* # ine must be taken .er* serious*! )ou shou% 2ght har% to make that ist as sma an% tight as
possibe "this appies to an* goa ists in the .ision %ocument as we&! An item in the priorit* # ist means 8(e
wi %ie without this!8 It %oes not mean things that are nice to ha.e or that we rea* want to ha.e: it gi.es the
tightest, eanest wa* to meet the project goas! 6or exampe, if we were bui%ing an automobie, the on* priorit*
# things wou% be the engine, tires, transmission, brakes, steering whee, an% pe%as! Priorit* E items wou% be
the %oors, win%shie%, air con%itioning, an% ra%io because *ou can get aroun% without those things! The core
functionait* of the automobie exists without them; *ou cou% ship it an% sti ca it a car!
Putting this ine in pace was awa*s .er* %iFcut; there was ots of arguing an% %ebating about which things
customers cou% i.e without or which things were more important than others! This was 2ne! (e wante% a of
the %ebating an% arguing to take pace ear*, but then mo.e on! As painfu as it wou% be, when we were
2nishe%, we4% ha.e a ist that ha% sur.i.e% the opinions an% perspecti.es of the team! (e cou% then go forwar%
an% execute, ha.ing refutations an% supporting arguments for the ist we4% ma%e! Ha.ing sharpene% it through
%ebate an% argument, we were rea%* for >=G of the common 7uestions or chaenges peope might ha.e ater
on "i!e!, wh* we were bui%ing brakes but not air con%itioning& an% cou% 7uick* %ispatch them: we4% hear% the
arguments before, an% we knew wh* the* %i%n4t ho% up!
The chaenge of prioriti1ation is awa*s more emotiona<ps*choogica than inteectua, %espite what peope sa*!
Hust ike %ieting to ose weight or bu%geting to sa.e mone*, eiminating things *ou want "but %on4t nee%&
re7uires being %iscipine%, committe%, an% focuse% on the important goas! Sa*ing 8stabiit* is important8 is one
thing, but stack ranking it against other important things is entire* %i3erent! Man* managers chicken out of this
process! The* he%ge, %ea*, an% %en* the tough choices, an% the resut is that the* set their projects up to fai!
+o tough choices means no progress! In the abstract, the wor% important means nothing! So, or%ere% ists an%
the %ecaration of a high priorit* # bar forces ea%ers an% the entire team to make tough %ecisions an% think
cear*!
'arit* is how *ou make things happen on projects! 5.er*one shows up to work each %a* with a strong sense of
what he is %oing, wh* he4s %oing it, an% how it reates to what the others are %oing! (hen the team asks
7uestions about wh* one thing is more important than another, there are cear an% ogica reasons for it! 5.en
when things change an% priorities are a%juste%, it4s a within the same fun%amenta s*stem of or%ere% ists an%
priorit* %esignations!
Priorities are power
Ha.e *ou e.er been in a tough argument that *ou thought wou% ne.er en%9 Perhaps haf the engineers fet
strong* for A, an% the other haf fet strong* for B! But then the smart team ea%er waks in, asks some
7uestions, %i.i%es the %iscussion in a new wa*, an% 7uick* gets e.er*one to agree! It4s happene% to me man*
times! (hen I was *ounger, I chake% this up to briiance: somehow that manager or ea% programmer was just
smarter than the rest of the peope in the room, an% saw things that we %i%n4t! But as I pai% more attention, an%
on occasion e.en aske% them afterwar% how the* %i% it, I reai1e% it was about ha.ing rock@soi% priorities! The*
ha% an or%ere% ist in their hea%s an% were abe to get other peope to frame the %iscussion aroun% it! Ioo%
priorities are power! The* eiminate secon%ar* .ariabes from the %iscussion, making it possibe to focus an%
reso.e issues!
If *ou ha.e priorities in pace, *ou can awa*s ask 7uestions in an* %iscussion that reframe the argument aroun%
a more usefu primar* consi%eration! This refreshes e.er*one4s sense of what success is, .isib* %i.i%ing the
uni.erse into two pies: things that are important an% things that are nice, but not important! Here are some
sampe 7uestions:
(hat probem are we tr*ing to so.e9
If there are mutipe probems, which one is most important9
How %oes this probem reate to or impact our goas9
(hat is the simpest wa* to 2x this that wi aow us to meet our goas9
If nothing ese, *ou wi reset the con.ersation to focus on the project goas, which e.er*one can agree with! If a
%ebate has gone on for hours, 2n%ing common groun% is *our best opportunit* to mo.ing the %iscussion towar%
a positi.e concusion!
Be a prioriti1ation machine
(hene.er I take% with programmers or testers an% hear% about their issues or chaenges, I reai1e% that m*
primar* .aue was in heping them focus! M* aim was to eiminate secon%ar* or tertiar* things from their pates
an% to hep them see a cear or%er of work! There are #,=== wa*s to impement a particuar web page %esign or
%atabase s*stem to spec, but on* a han%fu of them wi rea* nai the objecti.es! ,nowing this, I encourage%
programmers to seek me out if the* e.er face% a %ecision where the* were not sure which in.estment of time to
make next!
But instea% of micromanaging them "8Jo this! +o %o that! +o, %o it this wa*! Are *ou %one *et9 How about
now98&, I just ma%e them un%erstan% that I was there to hep them prioriti1e when the* nee%e% it! Because the*
%i%n4t ha.e the project@wi%e perspecti.e I %i%, m* .aue was in heping them to see, e.en if just for a moment,
how what the* were %oing 2t into the entire project! (hen the*4% spent a %a* %ebugging a mo%ue or running
unit tests, the* were often reie.e% to get some higher@e.e carit*, reassurance, an% con2%ence in what the*
were %oing! It often took on* a ?=@secon% con.ersation to make sure we were a sti on the same page!
(hene.er new information came to the project, it was m* job to interpret it "aone or through %iscussion with
others&, an% form it into a prioriti1e% ist of things we ha% to care about an% things we %i%n4t! /ften, I4% ha.e to
re.ise a pre.ious ist, a%justing it to respon% to the new information! A DP might change her min%! A usabiit*
stu%* might 2n% new issues! A competitor might make an unexpecte% change! Those prioriti1ations were i.ing,
breathing things, an% an* changes to our %irection or goas were re:ecte% %irect* an% imme%iate* in them!
Because I maintaine% the priorities, I enabe% the team to sta* focuse% on the important things an% actua*
make progress on them! Sometimes, I cou% reuse priorities %e2ne% b* m* superiors ".ision %ocuments, group
mission statements&; other times, I ha% to in.ent m* own from scratch in response to ambiguit* or unforeseen
situations! But more than an*thing ese, I was a prioriti1ation machine! If there is e.er a statue ma%e in honor of
goo% project managers, I suspect the inscription wou% sa* 8Bring me *our ran%omi1e%, *our righteous*
confuse%, *our sarcastic an% bitter masses of programmers *earning for carit*!8
Things Happen (hen )ou Sa* +o
/ne si%e e3ect of ha.ing priorities is how often *ou ha.e to sa* no! It4s one of the smaest wor%s in the 5ngish
anguage, *et man* peope ha.e troube sa*ing it! The probem is that if *ou can4t sa* no, *ou can4t ha.e
priorities! The uni.erse is a arge pace, but *our priorit* # ist shou% be .er* sma! Therefore, most of what
peope in the wor% "or on *our team& might think are great i%eas wi en% up not matching the goas of the
project! It %oesn4t mean their i%eas are ba%; it just means their i%eas won4t contribute to this particuar project!
So, a fun%amenta aw of the PM uni.erse is this: if *ou can4t sa* no, *ou can4t manage a project!
Sa*ing no starts at the top of an organi1ation! The most senior peope on a project wi %etermine whether
peope can actua* sa* no to re7uests! +o matter what the priorities sa*, if the ea% %e.eoper or manager
continua* sa*s *es to things that %on4t ji.e with the priorities, others wi foow! Programmers wi work on pet
features! PMs wi a%% "hi%%en& re7uirements! 5.en if these in%i.i%ua choices are goo%, because the team is no
onger foowing the same rues, nor working towar% the same priorities, con:icts wi occur! Sometimes, it wi be
%isagreements between programmers, but more often, the resut wi be %isjointe% 2na %esigns! Stabiit*,
performance, an% usabiit* wi a su3er! (ithout the focus of priorities, it4s har% to get a team to coor%inate on
making the same thing! The best ea%ers an% team managers know that the* ha.e to ea% the wa* in sa*ing no
to things that are out of scope, setting the bar for the entire team!
(hen *ou %o sa* no, an% make it stick, the project gains momentum! 5iminating tasks from peope4s pates
gi.es them more energ* an% moti.ation to focus an% work har% on what the* nee% to %o! The number of
meetings an% ran%om %iscussions wi %rop an% eFcienc* wi cimb! Momentum wi bui% aroun% sa*ing no:
others wi start %oing it in their own spheres of in:uence! In fact, I4.e aske% team members to %o this! I4% sa*, 8If
*ou e.er fee *ou4re being aske% to %o something that %oesn4t ji.e with our priorities, sa* no! /r te them that I
sai% no, an% the* nee% to tak to me! An% %on4t waste *our time arguing with them if the* compain0point them
m* wa*!8 I %i%n4t want them wasting their time %ebating priorities with peope because it was m* expertise, not
theirs! 5.en if the* ne.er face% these situations, I succee%e% in expressing how serious the priorities were an%
how wiing I was to work to %efen% them!
Master the man* wa*s to sa* no
Sometimes, *ou wi nee% to sa* no in %irect response to a feature re7uest! /ther times, *ou4 nee% to interject
*oursef into a con.ersation or meeting, i%entif* the con:ict with priorities *ou4.e o.erhear%, an% e3ecti.e* sa*
no to whate.er was being %iscusse%! To prepare *oursef for this, *ou nee% to know a of the %i3erent :a.ors
that the wor% no comes in:
No, this doesn't ft our priorities! If it is ear* in the project, *ou shou% make the argument for wh*
the current priorities are goo%, but hear peope out on wh* other priorities might make more sense! The*
might ha.e goo% i%eas or nee% carit* on the goas! But %o force the %iscussion to be reati.e to the
project priorities, an% not the abstract .aue of a feature or bug 2x re7uest! If it is ate in the project, *ou
can te them the* misse% the boat! 5.en if the priorities suck, the*4re not going to change on the basis
of one feature i%ea! The ater *ou are, the more se.ere the strateg* faiure nee%s to be to justif* goa
a%justments!
No, only if we hae time! If *ou keep *our priorities ean, there wi awa*s be man* .er* goo% i%eas
that %i%n4t make the cut! 5xpress this as a reati.e %ecision: the i%ea in 7uestion might be goo%, but not
goo% enough reati.e to the other work an% the project priorities! If the item is on the priorit* E ist,
con.e* that it4s possibe it wi be %one, but that no one shou% bet the farm assuming it wi happen!
No, only if you ma!e "insert impossi#le thing here$ happen! Sometimes, *ou can re%irect a
re7uest back onto the person who ma%e it! If *our DP asks *ou to a%% support for a new feature, te him
*ou can %o it on* if he cuts one of his other current priorit* # re7uests! This shifts the point of contention
awa* from *ou, an% towar% a tangibe, though probab* unattainabe, situation! This can aso be %one for
poitica or appro.a issues: 8If *ou can con.ince Sa* that this is a goo% i%ea, I4 consi%er it!8 Howe.er,
this can back2re! "(hat if he %oes con.ince Sa*9 /r worse, reai1es *ou4re sen%ing him on a wi% goose
chase9&
No. Ne%t release! Assuming *ou are working on a web site or software project that wi ha.e more
up%ates, o3er to reconsi%er the re7uest for the next reease! This shou% probab* happen an*wa* for a
priorit* E items! This is often cae% postponement or punting!
No. Neer. &er. 'eally! Some re7uests are so fun%amenta* out of ine with the ong@term goas that
the hammer has to come %own! 'ut the cor% now an% sa.e *oursef the time of answering the same
re7uest again ater! Sometimes it4s worth the e3ort to expain wh* "so that the*4 be more informe% next
time&! 5xampe: 8+o, 6re%! The web site search engine wi ne.er support the 5speranto anguage! +e.er!
5.er!8
,eeping It -ea
Some teams ha.e a better sense of reait* than others! )ou can 2n% man* stories of project teams that shippe%
their pro%uct months or *ears ate, or came in miions of %oars o.er bu%get "see -obert Iass4 Software
Runaways, Prentice Ha, #>>C&! Kitte b* itte, teams beie.e in tin* ies or misrepresentations of the truth about
what4s going on, an% si%e into %angerous an% unpro%ucti.e paces! As a rue, the further a team gets from
reait*, the har%er it is to make goo% things happen! Team ea%ers must pa* the roe of keeping their team
honest "in the sense that the team can ose touch with reait*, not that the* %eiberate* ie&, remin%ing peope
when the* are making up answers, ignoring probematic situations, or focusing on the wrong priorities!
I remember a meeting I was in *ears ago with a sma pro%uct team! The* were bui%ing something that the*
wante% m* team to use, an% the presentation focuse% on the new features an% technoogies their pro%uct wou%
ha.e! Sitting near the back of the room, I fet increasing* uncomfortabe with the presentation! +one of the
tough issues was being a%%resse% or e.en mentione%! Then I reai1e% the rea probem: b* not a%%ressing the
important issues, the* were wasting e.er*one4s time!
I ooke% aroun% the room an% reai1e% part of the probem: I was the on* ea% from m* organi1ation in
atten%ance! +orma*, I4% ha.e expecte% another PM or ea% programmer to ask tough 7uestions area%*! But
with the faces in the room, I %i%n4t know if an*one ese was comfortabe making wa.es when necessar*! A
thousan% 7uestions came to min%, an% I 7uick* raise% m* han%, uneashing a series of simpe 7uestions, one
after another! 8(hat is *our sche%ue9 (hen can *ou get working co%e to us9 (ho are *our other customers,
an% how wi *ou prioriti1e their re7uests against ours9 (h* is it in our interest to make ourse.es %epen%ent on
*ou an% *our team98 Their jaws %roppe%! The* were entire* unprepare%!
It was cear the* ha% not consi%ere% these 7uestions before! (orse, the* %i% not expect to ha.e to answer them
for potentia cients! I poite* expaine% that the* were not rea%* for this meeting! I apoogi1e% if m*
expectations were not ma%e cear when the meeting was arrange% "I thought the* were&! I to% them that
without those answers, this meeting was a waste of e.er*one4s time, incu%ing theirs! I suggeste% we postpone
the rest of the meeting unti the* ha% answers for these simpe 7uestions! The* sheepish* agree%, an% the
meeting en%e%!
In PM parance, what I %i% in this stor* was ca buL! This is in reference to the car% game BuL, where *ou win if
*ou get ri% of a the car%s in *our han%! In each turn of the game, a pa*er states which car%s he4s pa*ing as he
paces them face %own into a pie! He is not obigate% to te the truth! So, if at an* time another pa*er thinks
the 2rst pa*er is *ing, she can 8ca buL8 an% force the 2rst pa*er to show his car%s! If the accuser is right, the
2rst pa*er takes a of the car%s in the pie "a major setback&! Howe.er, if the accuser is wrong, she takes the
pie!
'aing buL makes things happen! If peope expect *ou wi ask them tough 7uestions, an% not hesitate to push
them har% unti *ou get answers, the* wi prepare for them before the* meet with *ou! The* wi not waste *our
or *our team4s time! -emember that a kin%s of %eception, incu%ing sef@%eception, work against projects! The
sooner the truth comes to ight, the sooner *ou can %o something about it! Because most peope a.oi% con:ict
an% prefer to preten% things are /, "e.en when there is e.i%ence the* are not&, someone has to push to get the
truth out! The more *ou can keep the truth out in the open, the more *our team can sta* ow to the groun%,
mo.ing at high spee%!
The chaenge with 7uestioning others is that it can run against the cuture of an in%i.i%ua or organi1ation!
Some cutures see 7uestioning as an insut or a ack of trust! The* ma* see attempts to keep things honest as
persona attacks, instea% of as genuine in7uiries into the truth! )ou ma* nee% to approach these situations more
forma* than I %i% in the stor*! Make a ist of 7uestions *ou expect peope to answer, an% pro.i%e it to them
before meetings! /r, create a ist of 7uestions that an*one in the organi1ation is free to ask an*one at an* time
"incu%ing DPs an% PMs&, an% post it on the wa in a conference room! If *ou make it pubic knowe%ge from %a*
one that buL wi be cae% at an* time, *ou can make it part of the cuture without insuting an*one! Howe.er,
ea%ers sti ha.e the bur%en of actua* caing buL from time to time, %emonstrating for the team that cutting
7uick* to the truth can be %one!
,now the 'ritica Path
In project management terminoog*, the critica path is the shortest se7uence of work that can compete the
project! In critica path ana*sis, a %iagram or :owchart is ma%e of a work items, showing which items are
%epen%ent on which others! If %one proper*, this %iagram shows where the bottenecks wi be! 6or exampe, if
features A, B, an% ' can4t be compete% unti J is %one, then J is on the critica path for that part of the project!
This is important because if J is %ea*e% or %one poor*, it wi serious* impact the competion of work items A,
B, an% '! It4s important then for a project manager to be abe to pan an% prioriti1e the critica path! Sometimes,
a reati.e* unimportant component on its own can be the critica %epen%enc* that pre.ents true priorit* # work
from being compete%! (ithout %oing critica path ana*sis, *ou might ne.er recogni1e this unti it is too ate!
6rom a higher@e.e perspecti.e, there is a critica path to a situations! The* %on4t nee% to be %iagramme% or
measure% to the same e.e of %etai, but the thought processes in assessing man* PM situations are simiar:
ook at the probem as a series of inks, an% see where the bottenecks or critica points are! (hich %ecisions or
actions are %epen%ent on which other %ecisions or actions9 Then consi%er if enough attention is being pai% to
them, or if the rea issue isn4t the one current* being %iscusse%! )ou %ramatica* acceerate a team b* putting
its attention %irect* on the eements, factors, an% %ecisions that are centra to progress!
Awa*s ha.e a sense for the critica path of:
The project4s engineering work "as %escribe% brie:* earier&
The project4s high@e.e %ecision@making process "who is sowing the team %own9&
The team4s processes for bui%ing co%e or triaging bugs "are there nee%ess forms, meetings, or
appro.as9&
The pro%uction process of propping content to the (eb or intranet
An* meeting, situation, or process that impacts project goas
Making things happen e3ecti.e* re7uires a strong sense of critica paths! An*time *ou wak into a room, rea% an
emai, or get in.o.e% in a %ecision, *ou must think through what the critica paths are! Is this rea* the core
issue9 (i this %iscussion or ine of thinking reso.e it9 6ocus *our energ* "or the room4s energ*& on a%%ressing
those consi%erations 2rst an% e.auating what nee%s to be %one to ensure those critica paths are ma%e shorter,
or resource% suFcient*, to pre.ent %ea*s! If *ou can nai the critica path, ess@critica issues wi more easi*
fa into pace!
6or some organi1ations, the fastest wa* to impro.e the "non@engineering& critica path is to %istribute authorit*
across the team! Instea% of re7uiring consensus, et in%i.i%uas make %ecisions an% use their own ju%gment as
to when consensus is nee%e%! Jo the same thing for appro.as, %ocumentation, forms, or other possibe
bureaucratic o.erhea% "see 'hapter #=&! /ften the best wa* of impro.ing critica paths in organi1ations is to
remo.e processes an% shift authorit* %own an% across a team, instea% of creating new processes or hierarchies!
Be -eentess
8The wor% respon%s to action, an% not much ese!8
0Scott A%ams
Man* smart peope can recogni1e when there is a probem, but few are wiing to expen% the energ* necessar*
to 2n% a soution, an% then summon the courage to %o it! There are awa*s easier wa*s: gi.e up, accept a partia
soution, procrastinate unti it goes awa* "2ngers crosse%&, or bame others! The har%er wa* is to take the
probem hea%@on an% resist gi.ing in to concusions that %on4t aow for satisfaction of the goas! Successfu
project managers simp* %o not gi.e up easi*! If something is important to the project, the* wi act aggressi.e*
0using an* means necessar*0to 2n% an answer or so.e the probem! This might mean reorgani1ing a
%*sfunctiona team, getting a %iFcut room of peope to agree on goas, 2n%ing answers to 7uestions, or setting
%isagreements between peope!
Sometimes, this means asking peope to %o things the* %on4t ike %oing, or raising 7uestions the* %on4t want to
answer! (ithout someone forcing those things to happen, the easier wa* out wi ten% to be chosen for *ou!
Man* projects consist of peope with speciai1e% roes who are unike* to take responsibiit* for things that are
be*on% their imite% scope "or that fa between the cracks of their roe an% someone ese4s&! Perhaps more
probematic is that most of us a.oi% con:ict! It4s often the PM who has to 7uestion peope, chaenge
assumptions, an% seek the truth, regar%ess of how uncomfortabe it might make others "athough the goa is to
%o this in a wa* that makes them as comfortabe as possibe&! PMs ha.e to be wiing to %o these things when
necessar*!
Man* times situations that initia* seem untenabe or intractabe crumbe un%erneath the ps*choogica e3ort of
a tenacious project manager! A cassic stor* about this attitu%e is the Apollo 13 mission! In his book Failure Is
Not an ption "Berkee* Pubishing, E==#&, Iene ,ran1 %escribes the e3ort that went into 2xing the ife@support
s*stem on the %amage% spacecraft! It was one of the har%est engineering chaenges the team face%, an% there
were gra.e %oubts among those with the most expertise that e.en a partia soution was possibe! ,ran1 took
the position that not on* wou% the* 2n% a wa*, the* wou% %o so in the imite% time aotte%! He refuse% to
accept an* eas* wa* out, an% he pushe% his team to expore aternati.es, reso.ing their %isputes an% focusing
their energ*! A three .ersions of the stor*, the 2m Apollo 13, ,ran14s book, an% !ost Moon "Pocket, #>>B& b* Him
Ko.e "the mission captain& an% He3re* ,uger, pro.i%e fascinating accounts of one of the greatest project
management an% probem@so.ing stories in histor*!
53ecti.e PMs simp* consi%er more aternati.es before gi.ing up than other peope %o! The* 7uestion the
assumptions that were eft unchaenge% b* others, because the* came from either a DP peope were afrai% of or
a source of superior expertise that no one fet the nee% to chaenge! The 7uestion 8How %o *ou know what *ou
know98 is the simpest wa* to carif* what is assume% an% what is rea, *et man* peope are afrai%, or forget, to
ask it! Being reentess means beie.ing that >>G of the time there is a soution to the probem "incu%ing, in
some cases, changing the %e2nition of the probem&, an% that if it can4t be foun% with the information at han%,
then %eeper an% more probing 7uestions nee% to be aske%, no matter who has to be chaenge%! The success of
the project has to come 2rst!
In m* *ears in the (in%ows %i.ision at Microsoft, I worke% for Hie 'ooperman, perhaps the most passionate
an% %e%icate% manager I4.e e.er ha%! I remember once coming into his oFce with a %iemma! M* team was
stuck on a compicate% probem in.o.ing both engineering an% poitica issues! (e nee%e% another organi1ation
to %o important work for us, which the* were unwiing to %o! I ha% brainstorme% with e.er*one in.o.e%, I ha%
soicite% opinions from other senior peope, but I was sti stuck! There %i%n4t seem to be a reasonabe soution,
*et this was something critica to the project, an% I knew gi.ing in wou% be unacceptabe! After expaining m*
situation, the con.ersation went something ike this: 8(hat ha.en4t *ou trie% *et98 I ma%e the mistake of
answering, 8I4.e trie% e.er*thing!8 He just aughe% at me! 85.er*thing9 How cou% *ou possib* ha.e trie%
e.er*thing9 If *ou4.e trie% e.er*thing, *ou4% ha.e foun% a choice *ou fee comfortabe with, which apparent*
*ou ha.en4t *et!8 (e foun% this funn* because we both knew exact* where the con.ersation was going!
He then aske% if I wante% some suggestions! /f course I sai% *es! (e ri3e% for a few minutes, back an% forth,
an% came up with a new ist of things to consi%er! 8(ho ha.en4t *ou cae% on the phone9 5mai isn4t goo% for
this kin% of thing! An% of a the peope on the other si%e0those who %isagree with *ou0who is most recepti.e
to *ou9 How har% ha.e *ou so% them on what *ou want9 Shou% I get in.o.e% an% work from abo.e *ou9 (ou%
that hep9 (hat about our DP9 How har% ha.e *ou pushe% engineering to 2n% a workaroun%9 A itte9 A ot9 As
har% as possibe9 Ji% *ou o3er to bu* them %rinks9 Jinner9 Ji% *ou tak to them one@on@one, or in a group9
,eep going, keep going, keep going! )ou wi 2n% a wa*! I trust *ou, an% I know *ou wi so.e this! ,eep going!8
He %i% two things for me: he remin%e% me that not on* %i% I ha.e aternati.es, but aso that it was sti m*
authorit* to make the %ecision! As tire% as I was, I eft his oFce con.ince% there were more paths to expore an%
that it was m* job to %o so! M* ownership of the issue, which he4% recon2rme%, hepe% moti.ate me to be
reentess! The soution was urking insi%e one of them, an% I just ha% to 2n% it! Kike the %o1ens of other issues I
was managing at the same time, I e.entua* foun% a soution "there was an engineering workaroun%&, but on*
because I hunte% for it: it was not going to come an% 2n% me!
Among other essons, I earne% from Hie that %iigence wins battes! If *ou make it cear that *ou are %ea%
serious an% wi 2ght to the en% about a particuar issue, *ou force more possibiities to arise! Peope wi
7uestion their assumptions if *ou ho% on to *ours ong enough! )ou push peope to consi%er things the* ha.en4t
consi%ere%, an% often that4s where the answer ies! 5.en in %isagreements or negotiations, if *ou know *ou4re
right, an% keep pushing har%, peope wi often gi.e in! Sometimes, the*4 gi.e in just to get *ou to ea.e them
aone! Being push*, pro.i%e% *ou4re not o3ensi.e, can be an e3ecti.e techni7ue a on its own!
Being reentess is fun%amenta to making things happen! There are so man* %i3erent wa*s for projects to si%e
into faiure that uness there is at east one emotiona force behin% the project0pushing it forwar%, seeking out
aternati.es, beie.ing there is awa*s a wa* out of e.er* probem an% trap0the project is unike* to succee%!
Ioo% PMs are that force! The* are compee% to keep mo.ing forwar%, awa*s on the ookout for something that
can be impro.e% in a faster or smarter wa*! The* seek out chaos an% con.ert it into carit*! As skeptica as
project managers nee% to be, the* are simutaneous* optimistic that a probems can be so.e% if enough
intensit* an% focus are appie%! 6or reasons the* themse.es cannot fu* expain, PMs continua* ho% a torch
up against ambiguit* an% %oubt, an% refuse to 7uit unti e.er* possibe aternati.e has been expore%! The*
beie.e that goo% thinking wins, an% that it takes work to 2n% goo% thoughts!
Be Sa..*
But being reentess %oesn4t mean *ou ha.e to knock on e.er* %oor, chase peope %own the hawa*, or sta* at
work unti *ou pass out at *our %esk! Sheer 7uantit* of e3ort can be nobe an% goo%, but awa*s ook for wa*s to
work smart rather than just har%! Be reentess in spirit, but ce.er an% sa..* in action! Hust because *ou refuse
to gi.e up %oesn4t mean *ou ha.e to su3er through min%ess, stupi%, or frustrating acti.ities "athough
sometimes the*4re una.oi%abe&! Kook for smart wa*s aroun% a probem or faster wa*s to reso.e them! Make
e3ecti.e use of the peope aroun% *ou instea% of assuming *ou ha.e to %o e.er*thing *oursef! But most
important*, be percepti.e of what4s going on aroun% *ou, with in%i.i%uas an% with teams!
A fun%amenta mistake man* PMs make is to forget to assess who the* are working with an% a%just their
approach accor%ing*! +a.* Seas an% Arm* rangers are traine% to carr* out missions on man* %i3erent kin%s of
terrain: %eserts, swamps, junges, tun%ra! (ithout this training, their e3ecti.eness wou% be imite%: the*4%
strugge to sur.i.e on unfamiiar terrain because their skis wou%n4t work "imagine a soi%er in green an% oi.e
camou:age, tr*ing to hi%e on a snow@co.ere% 2e%&! The 2rst esson the* earn is how to e.auate their
en.ironment an% consi%er what tactics an% strategies from their ski set wi work for where the* are! The same
is true for PMs! Instea% of geographic en.ironments, PMs must pa* attention to the %i3erent socia, poitica, an%
organi1ationa en.ironments the* are in, an% use the right approaches for where the* are!
Being sa..* an% en.ironment@aware is most important in the foowing situations:
Moti.ating an% inspiring peope
/rgani1ing teams an% panning for action
Setting arguments or breaking %ea%ocks
+egotiating with other organi1ations or cutures
Making arguments for resources
Persua%ing an*one of an*thing
Managing reports "personne&
Here4s the sa..* PM4s rough gui%e to e.auating an en.ironment! These 7uestions app* to an in%i.i%ua *ou
might be working with or to the arger team or group:
(hat )ommuni)ation styles are #eing used* Jirect or in%irect9 Are peope open* communicati.e,
or are the* reser.e%9 Are there common* accepte% wa*s to make certain kin%s of points9 Are peope
genera* e3ecti.e in using emai9 Meetings9 Are %ecisions ma%e open* or behin% cose% %oors9 Match
*our approaches to the ones that wi be e3ecti.e with whome.er *ou4re taking to!
+ow #road or narrow is the group's sense of humor* (hat topics are forbi%%en to augh at or
7uestion9 How are %eicate<%iFcut<contentious subjects or %ecisions han%e% b* others9
,re arguments won #ased on data* Kogica argument through %ebate9 A%herence to the project
goas9 (ho *es the ou%est9 (ho has the brownest nose9 'onsi%er making arguments that use the
st*e, format, or tone most paatabe to *our au%ience, whether it4s a one tester %own the ha or a room
fu of executi.es!
(ho is e-e)tie at doing "insert thing you are trying to do here$, and what )an . emulate or
learn from them* Pa* attention to what works! (ho are the stars9 (ho gets the most respect9 How are
the* thri.ing9 (ho is faiing here9 (h* are the* faiing9
.n terms of a)tual #ehaior, what alues are most important to this person or
group* Inteigence9 'ourage9 Spee%9 'arit*9 Patience9 /be%ience9 (hat beha.iors are east .aue% or
are %epore%9 Programmers an% managers might ha.e .er* %i3erent .aues! ,now what the other gu*
.aues before *ou tr* to con.ince him of something!
(hat is the organi/ational )ulture* 5.er* uni.ersit*, corporation, or team has a %i3erent set of
.aues buit into the cuture! If *ou %on4t think *our organi1ation has one, *ou4.e been there too ong an%
can4t see it an*more "or ma*be *ou ne.er saw it at a&! Some organi1ations .aue o*at* an% respect
abo.e inteigence an% in%i.i%uait*! /thers focus on work ethic an% commitment!
Jepen%ing on the answers to these 7uestions, a PM shou% make a%justments to how she %oes her work! 5.er*
time *ou enter another person4s oFce, or another meeting, there shou% awa*s be some a%justments ma%e!
Kike a Marine, assess the en.ironment an% then ju%ge the best route to get to the project goas! A.oi% taking the
har% roa% if there is a smarter wa* to get where *ou nee% to go!
Iueria tactics
Being sa..* means *ou are ooking for, an% wiing to take, the smarter route! The foowing ist contains tactics
that I4.e use% successfu* or ha.e been successfu* use% on me! (hie *our mieage ma* .ar* with them, I4m
sure this ist wi get *ou thinking of other sa..* wa*s to accompish what nee%s to be %one to meet *our goas!
Some of these ha.e risks, which I4 note, an% must be appie% carefu*! 5.en if *ou choose ne.er to use these
*oursef, b* being aware of them, *ou wi be sa..ier about what4s going on aroun% *ou!
0o to the sour)e! Jon4t %i*%a* with peope4s secon%han% interpretations of what someone sai%, an%
%on4t %epen% on written reports or emais for compex information! 6in% the actua person an% tak to him
%irect*! )ou can4t get new 7uestions answere% b* rea%ing reports or emais, an% often peope wi te *ou
important things that were inappropriate for written communication! Ioing to the source is awa*s more
reiabe an% .auabe than the aternati.es, an% it4s worth the e3ort re7uire%! 6or exampe, if two
programmers are arguing about what a thir% programmer sai%, get that thir% programmer in the room or
on the phone! Awa*s cut to the chase an% push others to %o the same!
Swit)h )ommuni)ation modes! If communication isn4t working, switch the mo%e! Instea% of emai, ca
them on the phone! Instea% of a phone ca, %rop b* their oFce! 5.er*one is more comfortabe in some
me%iums than others! "Ienera*, face to face, in front of a whiteboar%, trumps e.er*thing! Iet peope in
a room with a whiteboar% if the emai threa% on some issue gets out of contro!& Jon4t et the imitations
of a particuar technoog* stop *ou! Sometimes, switching mo%es gets *ou a %i3erent response, e.en if
*our re7uest is the same, because peope are more recepti.e to one mo%e o.er another! 6or an*thing
conse7uentia, it4s worth the mone* an% time to get on a pane, or %ri.e to their oFce, if it impro.es the
communication %*namic between *ou an% an important co@worker!
0et people alone! (hen *ou tak to someone pri.ate*, her %isposition towar% *ou is %i3erent than
when *ou tak to her in a arge group! In a meeting, important peope ha.e to craft what the* sa* to be
appropriate for a of the ears in the room! Sometimes, *ou4 hear ra%ica* %i3erent things %epen%ing on
who is in earshot! If *ou want a frank an% honest opinion, or an in@%epth intense con.ersation, *ou nee%
to get peope aone! Aso, consi%er peope of in:uence: if Him trusts Beth4s opinion, an% *ou want to
con.ince Him, if *ou can con.ince Beth 2rst, bring her aong! Jon4t ambush an*one, but %on4t sh* awa*
from ining things up to make progress happen!
+unt people down! If something is urgent an% *ou are not getting the response time *ou nee%, car.e
out time on *our sche%ue to stake out the person4s oFce or cubice! I4.e %one this man* times! If he
wasn4t answering m* phone cas or emais, he4% soon come back from a meeting an% 2n% me sitting b*
his %oor! He4% usua* be caught so o3 guar% that I4% ha.e a negotiating a%.antage! Jon4t be afrai% to go
after peope if *ou nee% something from them! 6in% them in the co3ee room! Kook for them in the cafe at
unchtime! Ask their secretar* what meetings the* are in an% wait outsi%e! Be poite, but hunt an% get
what *ou nee%! "Howe.er, pease %o not cross o.er into their persona i.es! If *ou hunt information we,
*ou shou%n4t e.er e.en nee% to cross this particuar ine!&
+ide! If *ou are behin% on work an% nee% bocks of time to get caught up, become in.isibe! /n
occasion, I4.e stake% out a conference room "in a neighboring bui%ing& an% to% on* the peope who
rea* might nee% me where I was! I caught up on emai, specs, empo*ee e.auations, or an*thing
important that wasn4t getting %one, without being interrupte%! 6or smaer orgs, working from home or a
co3ee shop can ha.e the same e3ect "wireess makes this eas* these %a*s&! I awa*s encourage% m*
reports to %o this whene.er the* fet it necessar*! Mninterrupte% time can be har% for PMs to 2n%, so if
*ou can4t 2n% it, *ou ha.e to make it!
0et adi)e! Jon4t :* soo without a map uness *ou ha.e to! In a gi.en situation, consi%er who in.o.e%
thinks most high* of *ou, or who ma* ha.e usefu a%.ice for how *ou can get what *ou nee%! Make use
of an* expertise or experience *ou ha.e access to through others! Pu them asi%e an% ask them for it!
This can be about a person, a %ecision, a pan, an*thing! 8He* Bob, I4% ike *our a%.ice on this bu%get! Jo
*ou ha.e a few minutes98 /r, 8Hane, I4m tr*ing to work with Sam on this issue! An* a%.ice on the best
wa* to con.ince him to cut this feature98 6or man* peope, simp* asking their a%.ice wi score *ou
cre%ibiit* points: it4s an act of respect to ask for someone4s opinion!
1all in faors, #eg, and #ri#e! Make use of the cre%ibiit* or generosit* *ou4.e %e.eope% a reputation
for! If *ou nee% an engineer to %o extra work for *ou, either because *ou misse% something or a ate
re7uirement came in, ask her to %o *ou a fa.or! Io outsi%e the boun%aries of the strict working
reationship, an% ask! /3er to bu* her %inner "NE= is often we worth whate.er the fa.or is&, or te her
that *ou owe her one "an% %o ho% *oursef to this&! The worst thing that can happen is that she4 sa* no!
The more fa.ors *ou4.e %one for others, the more chips *ou4 ha.e to bank on! Aso, consi%er working
three@wa* tra%es "e!g!, in the game Setters of 'attan& if *ou know of something she wants that *ou can
get from someone ese! It4s not unethica to o3er peope things that wi con.ince them to hep with work
that nee%s to be %one!
2lay people o- ea)h other! This %oesn4t ha.e to be e.i0if *ou4re .er* carefu! If Sam gi.es *ou a
work estimate of #= %a*s, which *ou think is bogus, go an% ask Bob! If Bob sa*s something ess than #=
%a*s, go back to Sam, with Bob! A con.ersation wi imme%iate* ensue about what the work estimate
rea* shou% be! If *ou %o this once, no engineer wi e.er gi.e *ou bogus estimates again "*ou4.e cae%
buL&! Howe.er, %epen%ing on Sam4s personait*, this ma* cost *ou reationship points with him, so %o it
as tactfu* as possibe, an% on* when necessar*! Ioo% ea% programmers shou% be caing estimate
bu3s on their own, but if the* %on4t, it4s up to *ou!
3uy people )o-ee and tasty things! This soun%s stupi%, but I4.e foun% that peope I4.e argue% with
for %a*s on en% are somehow more recepti.e o.er a nice cup of co3ee at a oca co3ee shop! 'hange the
%*namic of the reationship: no matter how much *ou ike or %on4t ike the person, make the in.itation
an% in.est the E= secon%s of e3ort it re7uires! 5.en if he sa*s 8+o, wh* can4t we tak here98 *ou4.e ost
nothing! Mo.ing the con.ersation to a %i3erent ocation, perhaps one ess forma, can hep him open up
to aternati.es he wou%n4t consi%er before! Think bioogica*: humans are in better moo%s after the*4.e
eaten a 2ne mea or when the* are in more peasant surroun%ings! I4.e seen PMs who keep %oughnuts or
cookies "as we as rum an% scotch& in their oFce! Is that an act of goo%wi9 )es !!! but there are
ps*choogica bene2ts to making sure the peope *ou are working with are we fe% an% associate *ou
with goo% things!
Summar*
5.er*thing can be represente% in an or%ere% ist! Most of the work of project management is correct*
prioriti1ing things an% ea%ing the team in carr*ing them out!
The three most basic or%ere% ists are: project goas ".ision&, ist of features, an% ist of work items! The*
shou% awa*s be in s*nc with each other! 5ach work item contributes to a feature, an% each feature
contributes to a goa!
There is a bright *eow ine between priorit* # work an% e.er*thing ese!
Things happen when *ou sa* no! If *ou can4t sa* no, *ou e3ecti.e* ha.e no priorities!
The PM has to keep the team honest an% keep them cose to reait*!
,nowing the critica path in engineering an% team processes enabes eFcienc*!
)ou must be both reentess an% sa..* to make things happen!